• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
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// - PUFFDIFF: Read the data in src_extents in the old partition, perform
81//   puffpatch with the attached data and write the new data to dst_extents in
82//   the new partition.
83//
84// The operations allowed in the payload (supported by the client) depend on the
85// major and minor version. See InstallOperation.Type bellow for details.
86
87syntax = "proto2";
88
89package chromeos_update_engine;
90option optimize_for = LITE_RUNTIME;
91
92// Data is packed into blocks on disk, always starting from the beginning
93// of the block. If a file's data is too large for one block, it overflows
94// into another block, which may or may not be the following block on the
95// physical partition. An ordered list of extents is another
96// representation of an ordered list of blocks. For example, a file stored
97// in blocks 9, 10, 11, 2, 18, 12 (in that order) would be stored in
98// extents { {9, 3}, {2, 1}, {18, 1}, {12, 1} } (in that order).
99// In general, files are stored sequentially on disk, so it's more efficient
100// to use extents to encode the block lists (this is effectively
101// run-length encoding).
102// A sentinel value (kuint64max) as the start block denotes a sparse-hole
103// in a file whose block-length is specified by num_blocks.
104
105// Signatures: Updates may be signed by the OS vendor. The client verifies
106// an update's signature by hashing the entire download. The section of the
107// download that contains the signature is at the end of the file, so when
108// signing a file, only the part up to the signature part is signed.
109// Then, the client looks inside the download's Signatures message for a
110// Signature message that it knows how to handle. Generally, a client will
111// only know how to handle one type of signature, but an update may contain
112// many signatures to support many different types of client. Then client
113// selects a Signature message and uses that, along with a known public key,
114// to verify the download. The public key is expected to be part of the
115// client.
116
117message Extent {
118  optional uint64 start_block = 1;
119  optional uint64 num_blocks = 2;
120}
121
122message Signatures {
123  message Signature {
124    optional uint32 version = 1;
125    optional bytes data = 2;
126  }
127  repeated Signature signatures = 1;
128}
129
130message PartitionInfo {
131  optional uint64 size = 1;
132  optional bytes hash = 2;
133}
134
135// Describe an image we are based on in a human friendly way.
136// Examples:
137//   dev-channel, x86-alex, 1.2.3, mp-v3
138//   nplusone-channel, x86-alex, 1.2.4, mp-v3, dev-channel, 1.2.3
139//
140// All fields will be set, if this message is present.
141message ImageInfo {
142  optional string board = 1;
143  optional string key = 2;
144  optional string channel = 3;
145  optional string version = 4;
146
147  // If these values aren't present, they should be assumed to match
148  // the equivalent value above. They are normally only different for
149  // special image types such as nplusone images.
150  optional string build_channel = 5;
151  optional string build_version = 6;
152}
153
154message InstallOperation {
155  enum Type {
156    REPLACE = 0;  // Replace destination extents w/ attached data
157    REPLACE_BZ = 1;  // Replace destination extents w/ attached bzipped data
158    MOVE = 2;  // Move source extents to destination extents
159    BSDIFF = 3;  // The data is a bsdiff binary diff
160
161    // On minor version 2 or newer, these operations are supported:
162    SOURCE_COPY = 4; // Copy from source to target partition
163    SOURCE_BSDIFF = 5; // Like BSDIFF, but read from source partition
164
165    // On minor version 3 or newer and on major version 2 or newer, these
166    // operations are supported:
167    REPLACE_XZ = 8; // Replace destination extents w/ attached xz data.
168
169    // On minor version 4 or newer, these operations are supported:
170    ZERO = 6;  // Write zeros in the destination.
171    DISCARD = 7;  // Discard the destination blocks, reading as undefined.
172    BROTLI_BSDIFF = 10;  // Like SOURCE_BSDIFF, but compressed with brotli.
173
174    // On minor version 5 or newer, these operations are supported:
175    PUFFDIFF = 9;  // The data is in puffdiff format.
176  }
177  required Type type = 1;
178  // The offset into the delta file (after the protobuf)
179  // where the data (if any) is stored
180  optional uint32 data_offset = 2;
181  // The length of the data in the delta file
182  optional uint32 data_length = 3;
183
184  // Ordered list of extents that are read from (if any) and written to.
185  repeated Extent src_extents = 4;
186  // Byte length of src, equal to the number of blocks in src_extents *
187  // block_size. It is used for BSDIFF and SOURCE_BSDIFF, because we need to
188  // pass that external program the number of bytes to read from the blocks we
189  // pass it.  This is not used in any other operation.
190  optional uint64 src_length = 5;
191
192  repeated Extent dst_extents = 6;
193  // Byte length of dst, equal to the number of blocks in dst_extents *
194  // block_size. Used for BSDIFF and SOURCE_BSDIFF, but not in any other
195  // operation.
196  optional uint64 dst_length = 7;
197
198  // Optional SHA 256 hash of the blob associated with this operation.
199  // This is used as a primary validation for http-based downloads and
200  // as a defense-in-depth validation for https-based downloads. If
201  // the operation doesn't refer to any blob, this field will have
202  // zero bytes.
203  optional bytes data_sha256_hash = 8;
204
205  // Indicates the SHA 256 hash of the source data referenced in src_extents at
206  // the time of applying the operation. If present, the update_engine daemon
207  // MUST read and verify the source data before applying the operation.
208  optional bytes src_sha256_hash = 9;
209}
210
211// Describes the update to apply to a single partition.
212message PartitionUpdate {
213  // A platform-specific name to identify the partition set being updated. For
214  // example, in Chrome OS this could be "ROOT" or "KERNEL".
215  required string partition_name = 1;
216
217  // Whether this partition carries a filesystem with post-install program that
218  // must be run to finalize the update process. See also |postinstall_path| and
219  // |filesystem_type|.
220  optional bool run_postinstall = 2;
221
222  // The path of the executable program to run during the post-install step,
223  // relative to the root of this filesystem. If not set, the default "postinst"
224  // will be used. This setting is only used when |run_postinstall| is set and
225  // true.
226  optional string postinstall_path = 3;
227
228  // The filesystem type as passed to the mount(2) syscall when mounting the new
229  // filesystem to run the post-install program. If not set, a fixed list of
230  // filesystems will be attempted. This setting is only used if
231  // |run_postinstall| is set and true.
232  optional string filesystem_type = 4;
233
234  // If present, a list of signatures of the new_partition_info.hash signed with
235  // different keys. If the update_engine daemon requires vendor-signed images
236  // and has its public key installed, one of the signatures should be valid
237  // for /postinstall to run.
238  repeated Signatures.Signature new_partition_signature = 5;
239
240  optional PartitionInfo old_partition_info = 6;
241  optional PartitionInfo new_partition_info = 7;
242
243  // The list of operations to be performed to apply this PartitionUpdate. The
244  // associated operation blobs (in operations[i].data_offset, data_length)
245  // should be stored contiguously and in the same order.
246  repeated InstallOperation operations = 8;
247
248  // Whether a failure in the postinstall step for this partition should be
249  // ignored.
250  optional bool postinstall_optional = 9;
251}
252
253message DeltaArchiveManifest {
254  // Only present in major version = 1. List of install operations for the
255  // kernel and rootfs partitions. For major version = 2 see the |partitions|
256  // field.
257  repeated InstallOperation install_operations = 1;
258  repeated InstallOperation kernel_install_operations = 2;
259
260  // (At time of writing) usually 4096
261  optional uint32 block_size = 3 [default = 4096];
262
263  // If signatures are present, the offset into the blobs, generally
264  // tacked onto the end of the file, and the length. We use an offset
265  // rather than a bool to allow for more flexibility in future file formats.
266  // If either is absent, it means signatures aren't supported in this
267  // file.
268  optional uint64 signatures_offset = 4;
269  optional uint64 signatures_size = 5;
270
271  // Only present in major version = 1. Partition metadata used to validate the
272  // update. For major version = 2 see the |partitions| field.
273  optional PartitionInfo old_kernel_info = 6;
274  optional PartitionInfo new_kernel_info = 7;
275  optional PartitionInfo old_rootfs_info = 8;
276  optional PartitionInfo new_rootfs_info = 9;
277
278  // old_image_info will only be present for delta images.
279  optional ImageInfo old_image_info = 10;
280
281  optional ImageInfo new_image_info = 11;
282
283  // The minor version, also referred as "delta version", of the payload.
284  optional uint32 minor_version = 12 [default = 0];
285
286  // Only present in major version >= 2. List of partitions that will be
287  // updated, in the order they will be updated. This field replaces the
288  // |install_operations|, |kernel_install_operations| and the
289  // |{old,new}_{kernel,rootfs}_info| fields used in major version = 1. This
290  // array can have more than two partitions if needed, and they are identified
291  // by the partition name.
292  repeated PartitionUpdate partitions = 13;
293
294  // The maximum timestamp of the OS allowed to apply this payload.
295  // Can be used to prevent downgrading the OS.
296  optional int64 max_timestamp = 14;
297}
298