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 84package chromeos_update_engine; 85option 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 112message Extent { 113 optional uint64 start_block = 1; 114 optional uint64 num_blocks = 2; 115} 116 117message Signatures { 118 message Signature { 119 optional uint32 version = 1; 120 optional bytes data = 2; 121 } 122 repeated Signature signatures = 1; 123} 124 125message 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. 136message 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 149message 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. 203message 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 240message 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