Home | History | Annotate | Download | only in update_engine
      1 //
      2 // Copyright (C) 2010 The Android Open Source Project
      3 //
      4 // Licensed under the Apache License, Version 2.0 (the "License");
      5 // you may not use this file except in compliance with the License.
      6 // You may obtain a copy of the License at
      7 //
      8 //      http://www.apache.org/licenses/LICENSE-2.0
      9 //
     10 // Unless required by applicable law or agreed to in writing, software
     11 // distributed under the License is distributed on an "AS IS" BASIS,
     12 // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
     13 // See the License for the specific language governing permissions and
     14 // limitations under the License.
     15 //
     16 
     17 // Update file format: A delta update file contains all the deltas needed
     18 // to update a system from one specific version to another specific
     19 // version. The update format is represented by this struct pseudocode:
     20 // struct delta_update_file {
     21 //   char magic[4] = "CrAU";
     22 //   uint64 file_format_version;
     23 //   uint64 manifest_size;  // Size of protobuf DeltaArchiveManifest
     24 //
     25 //   // Only present if format_version > 1:
     26 //   uint32 metadata_signature_size;
     27 //
     28 //   // The Bzip2 compressed DeltaArchiveManifest
     29 //   char manifest[];
     30 //
     31 //   // The signature of the metadata (from the beginning of the payload up to
     32 //   // this location, not including the signature itself). This is a serialized
     33 //   // Signatures message.
     34 //   char medatada_signature_message[metadata_signature_size];
     35 //
     36 //   // Data blobs for files, no specific format. The specific offset
     37 //   // and length of each data blob is recorded in the DeltaArchiveManifest.
     38 //   struct {
     39 //     char data[];
     40 //   } blobs[];
     41 //
     42 //   // These two are not signed:
     43 //   uint64 payload_signatures_message_size;
     44 //   char payload_signatures_message[];
     45 //
     46 // };
     47 
     48 // The DeltaArchiveManifest protobuf is an ordered list of InstallOperation
     49 // objects. These objects are stored in a linear array in the
     50 // DeltaArchiveManifest. Each operation is applied in order by the client.
     51 
     52 // The DeltaArchiveManifest also contains the initial and final
     53 // checksums for the device.
     54 
     55 // The client will perform each InstallOperation in order, beginning even
     56 // before the entire delta file is downloaded (but after at least the
     57 // protobuf is downloaded). The types of operations are explained:
     58 // - REPLACE: Replace the dst_extents on the drive with the attached data,
     59 //   zero padding out to block size.
     60 // - REPLACE_BZ: bzip2-uncompress the attached data and write it into
     61 //   dst_extents on the drive, zero padding to block size.
     62 // - MOVE: Copy the data in src_extents to dst_extents. Extents may overlap,
     63 //   so it may be desirable to read all src_extents data into memory before
     64 //   writing it out.
     65 // - SOURCE_COPY: Copy the data in src_extents in the old partition to
     66 //   dst_extents in the new partition. There's no overlapping of data because
     67 //   the extents are in different partitions.
     68 // - BSDIFF: Read src_length bytes from src_extents into memory, perform
     69 //   bspatch with attached data, write new data to dst_extents, zero padding
     70 //   to block size.
     71 // - SOURCE_BSDIFF: Read the data in src_extents in the old partition, perform
     72 //   bspatch with the attached data and write the new data to dst_extents in the
     73 //   new partition.
     74 // - ZERO: Write zeros to the destination dst_extents.
     75 // - DISCARD: Discard the destination dst_extents blocks on the physical medium.
     76 //   the data read from those block is undefined.
     77 // - REPLACE_XZ: Replace the dst_extents with the contents of the attached
     78 //   xz file after decompression. The xz file should only use crc32 or no crc at
     79 //   all to be compatible with xz-embedded.
     80 //
     81 // The operations allowed in the payload (supported by the client) depend on the
     82 // major and minor version. See InstallOperation.Type bellow for details.
     83 
     84 package chromeos_update_engine;
     85 option optimize_for = LITE_RUNTIME;
     86 
     87 // Data is packed into blocks on disk, always starting from the beginning
     88 // of the block. If a file's data is too large for one block, it overflows
     89 // into another block, which may or may not be the following block on the
     90 // physical partition. An ordered list of extents is another
     91 // representation of an ordered list of blocks. For example, a file stored
     92 // in blocks 9, 10, 11, 2, 18, 12 (in that order) would be stored in
     93 // extents { {9, 3}, {2, 1}, {18, 1}, {12, 1} } (in that order).
     94 // In general, files are stored sequentially on disk, so it's more efficient
     95 // to use extents to encode the block lists (this is effectively
     96 // run-length encoding).
     97 // A sentinel value (kuint64max) as the start block denotes a sparse-hole
     98 // in a file whose block-length is specified by num_blocks.
     99 
    100 // Signatures: Updates may be signed by the OS vendor. The client verifies
    101 // an update's signature by hashing the entire download. The section of the
    102 // download that contains the signature is at the end of the file, so when
    103 // signing a file, only the part up to the signature part is signed.
    104 // Then, the client looks inside the download's Signatures message for a
    105 // Signature message that it knows how to handle. Generally, a client will
    106 // only know how to handle one type of signature, but an update may contain
    107 // many signatures to support many different types of client. Then client
    108 // selects a Signature message and uses that, along with a known public key,
    109 // to verify the download. The public key is expected to be part of the
    110 // client.
    111 
    112 message Extent {
    113   optional uint64 start_block = 1;
    114   optional uint64 num_blocks = 2;
    115 }
    116 
    117 message Signatures {
    118   message Signature {
    119     optional uint32 version = 1;
    120     optional bytes data = 2;
    121   }
    122   repeated Signature signatures = 1;
    123 }
    124 
    125 message PartitionInfo {
    126   optional uint64 size = 1;
    127   optional bytes hash = 2;
    128 }
    129 
    130 // Describe an image we are based on in a human friendly way.
    131 // Examples:
    132 //   dev-channel, x86-alex, 1.2.3, mp-v3
    133 //   nplusone-channel, x86-alex, 1.2.4, mp-v3, dev-channel, 1.2.3
    134 //
    135 // All fields will be set, if this message is present.
    136 message ImageInfo {
    137   optional string board = 1;
    138   optional string key = 2;
    139   optional string channel = 3;
    140   optional string version = 4;
    141 
    142   // If these values aren't present, they should be assumed to match
    143   // the equivalent value above. They are normally only different for
    144   // special image types such as nplusone images.
    145   optional string build_channel = 5;
    146   optional string build_version = 6;
    147 }
    148 
    149 message InstallOperation {
    150   enum Type {
    151     REPLACE = 0;  // Replace destination extents w/ attached data
    152     REPLACE_BZ = 1;  // Replace destination extents w/ attached bzipped data
    153     MOVE = 2;  // Move source extents to destination extents
    154     BSDIFF = 3;  // The data is a bsdiff binary diff
    155 
    156     // On minor version 2 or newer, these operations are supported:
    157     SOURCE_COPY = 4; // Copy from source to target partition
    158     SOURCE_BSDIFF = 5; // Like BSDIFF, but read from source partition
    159 
    160     // On minor version 3 or newer and on major version 2 or newer, these
    161     // operations are supported:
    162     ZERO = 6;  // Write zeros in the destination.
    163     DISCARD = 7;  // Discard the destination blocks, reading as undefined.
    164     REPLACE_XZ = 8; // Replace destination extents w/ attached xz data.
    165 
    166     // On minor version 4 or newer, these operations are supported:
    167     IMGDIFF = 9; // The data is in imgdiff format.
    168   }
    169   required Type type = 1;
    170   // The offset into the delta file (after the protobuf)
    171   // where the data (if any) is stored
    172   optional uint32 data_offset = 2;
    173   // The length of the data in the delta file
    174   optional uint32 data_length = 3;
    175 
    176   // Ordered list of extents that are read from (if any) and written to.
    177   repeated Extent src_extents = 4;
    178   // Byte length of src, equal to the number of blocks in src_extents *
    179   // block_size. It is used for BSDIFF, because we need to pass that
    180   // external program the number of bytes to read from the blocks we pass it.
    181   // This is not used in any other operation.
    182   optional uint64 src_length = 5;
    183 
    184   repeated Extent dst_extents = 6;
    185   // Byte length of dst, equal to the number of blocks in dst_extents *
    186   // block_size. Used for BSDIFF, but not in any other operation.
    187   optional uint64 dst_length = 7;
    188 
    189   // Optional SHA 256 hash of the blob associated with this operation.
    190   // This is used as a primary validation for http-based downloads and
    191   // as a defense-in-depth validation for https-based downloads. If
    192   // the operation doesn't refer to any blob, this field will have
    193   // zero bytes.
    194   optional bytes data_sha256_hash = 8;
    195 
    196   // Indicates the SHA 256 hash of the source data referenced in src_extents at
    197   // the time of applying the operation. If present, the update_engine daemon
    198   // MUST read and verify the source data before applying the operation.
    199   optional bytes src_sha256_hash = 9;
    200 }
    201 
    202 // Describes the update to apply to a single partition.
    203 message PartitionUpdate {
    204   // A platform-specific name to identify the partition set being updated. For
    205   // example, in Chrome OS this could be "ROOT" or "KERNEL".
    206   required string partition_name = 1;
    207 
    208   // Whether this partition carries a filesystem with post-install program that
    209   // must be run to finalize the update process. See also |postinstall_path| and
    210   // |filesystem_type|.
    211   optional bool run_postinstall = 2;
    212 
    213   // The path of the executable program to run during the post-install step,
    214   // relative to the root of this filesystem. If not set, the default "postinst"
    215   // will be used. This setting is only used when |run_postinstall| is set and
    216   // true.
    217   optional string postinstall_path = 3;
    218 
    219   // The filesystem type as passed to the mount(2) syscall when mounting the new
    220   // filesystem to run the post-install program. If not set, a fixed list of
    221   // filesystems will be attempted. This setting is only used if
    222   // |run_postinstall| is set and true.
    223   optional string filesystem_type = 4;
    224 
    225   // If present, a list of signatures of the new_partition_info.hash signed with
    226   // different keys. If the update_engine daemon requires vendor-signed images
    227   // and has its public key installed, one of the signatures should be valid
    228   // for /postinstall to run.
    229   repeated Signatures.Signature new_partition_signature = 5;
    230 
    231   optional PartitionInfo old_partition_info = 6;
    232   optional PartitionInfo new_partition_info = 7;
    233 
    234   // The list of operations to be performed to apply this PartitionUpdate. The
    235   // associated operation blobs (in operations[i].data_offset, data_length)
    236   // should be stored contiguously and in the same order.
    237   repeated InstallOperation operations = 8;
    238 }
    239 
    240 message DeltaArchiveManifest {
    241   // Only present in major version = 1. List of install operations for the
    242   // kernel and rootfs partitions. For major version = 2 see the |partitions|
    243   // field.
    244   repeated InstallOperation install_operations = 1;
    245   repeated InstallOperation kernel_install_operations = 2;
    246 
    247   // (At time of writing) usually 4096
    248   optional uint32 block_size = 3 [default = 4096];
    249 
    250   // If signatures are present, the offset into the blobs, generally
    251   // tacked onto the end of the file, and the length. We use an offset
    252   // rather than a bool to allow for more flexibility in future file formats.
    253   // If either is absent, it means signatures aren't supported in this
    254   // file.
    255   optional uint64 signatures_offset = 4;
    256   optional uint64 signatures_size = 5;
    257 
    258   // Only present in major version = 1. Partition metadata used to validate the
    259   // update. For major version = 2 see the |partitions| field.
    260   optional PartitionInfo old_kernel_info = 6;
    261   optional PartitionInfo new_kernel_info = 7;
    262   optional PartitionInfo old_rootfs_info = 8;
    263   optional PartitionInfo new_rootfs_info = 9;
    264 
    265   // old_image_info will only be present for delta images.
    266   optional ImageInfo old_image_info = 10;
    267 
    268   optional ImageInfo new_image_info = 11;
    269 
    270   // The minor version, also referred as "delta version", of the payload.
    271   optional uint32 minor_version = 12 [default = 0];
    272 
    273   // Only present in major version >= 2. List of partitions that will be
    274   // updated, in the order they will be updated. This field replaces the
    275   // |install_operations|, |kernel_install_operations| and the
    276   // |{old,new}_{kernel,rootfs}_info| fields used in major version = 1. This
    277   // array can have more than two partitions if needed, and they are identified
    278   // by the partition name.
    279   repeated PartitionUpdate partitions = 13;
    280 }
    281