With the change in vboot_signer (CL:744257), an additional parameter
is required to vboot_signer script. This change adds the required
parameter to releasetools as well.
BUG=23076037
Change-Id: Ice5329578b3a9bc459e278a9d404a1981b35ca88
Signed-off-by: Furquan Shaikh <furquan@google.com>
dm-verity may touch some blocks that are not in the care_map due to
block device read-ahead. It will fail if such blocks contain
non-zeroes. As a workaround, we mark them as extended blocks and
zero out explicitly to avoid dm-verity failures.
Bug: 20881595
Change-Id: I54e24e70ad822c0d6d7af43301f74d24505f4461
Clockwork builds may rename init.rc to init.core.rc. Change the OTA
script to scan all init.*.rc files to determine the proper location for
install-recovery.sh.
Bug: 22128990
Change-Id: If96bd0b81090683ad0bbfddb735d390204849d9f
If there is a SELinux context label in the recovery.fstab, we should
honor that when mounting the partition.
Bug: 19764039
Change-Id: I4df71a092b418cd340a18b2e3b0936de33d8e3f5
Similar to the assertations in file-based OTA, we perform verification
for block-based OTAs (BBOTAs) after updating a partition, for both of
the incremental and full OTAs. It increases the update time (~20s on
Nexus 6), but will capture unnoticed errors right away.
Bug: 21500869
Change-Id: I0f8b27734caaa0f41f9c1b904d55af2112784a68
(cherry picked from commit 68658c0f4f)
When passing a ZipInfo instance to common.ZipWriteStr(), the
external_attr attribute should not be overwritten unless specified.
We didn't have the issue previously because we were calling
ZipFile.writestr() directly until [1] merged.
[1] commit 2ed665a033.
Bug: http://b/21309935
Change-Id: I8c0190362c60d7d78965ecfe5e484f8398ddc5f2
(cherry picked from commit 9773465409)
In ext4 filesystems, some blocks might be changed even being mounted
R/O, such as the superblock (block 0). We need to exclude such blocks
from integrity verification. Plus such blocks should always be
written to the target by copying instead of patching.
Bug: http://b/20939131
Change-Id: I657025b7b1ad50d4365e7b18dc39308facfe864e
(cherry picked from commit ff7778166b)
In order to work around the zip 2GiB limit, we need to wrap the related
functions in zipfile. Calls to those functions should always be replaced
with calls to the wrappers instead.
Bug: 18015246
Change-Id: I499574cee51ec4804bc10cbefe0b17940afed918
(cherry picked from commit 2ed665a033)
It's not necessary to call block_image_verify for the most common
case where we attempt an update for the first time and the target
partition has expected contents. It is sufficient to confirm that
the target partition is intact.
Computing a hash is much faster than simulating the update, which
means this change should make the update speed for v3 much closer
to v2 for the common case. If the update was interrupted, this is
going to make resuming somewhat slower, of course. Hopefully this
should be rather rare.
Bug: 20309033
Change-Id: I04792f3681bf2cd5d9a4e1c41eb883c7f26c6f58
Allow dm-verity to be enabled without boot and recovery images being
signed. This makes it possible to enable only dm-verity to detect
corruption without confusing bootloaders that do not understand signed
images.
Bug: 19985143
Change-Id: Ie52c6ff595faa7a5c1f1bc1b37f6899c4d0c7001
Add vboot properties to the dictionary file, which will be packed into
the target_files zip. Add support in packaging and OTA scripts to
sign the generated bootable images (boot.img and recovery.img) when
vboot is enabled.
Change-Id: I08758ced03d173219415bca762bbdb66c464a9f5
(cherry picked from commit 5d5a3bd9e8d8b14b71d1b2105417a2958d13d3d2)
This caught a few bugs/syntax errors (a few character classes were not
escaped properly in regex patterns, some indentation was illegal,
etc).
Change-Id: I50637607524e68c4fb9cad7167f58a46b8d26b2c
Python 2.7's zipfile implementation wrongly thinks that zip64 is
required for files larger than 2GiB. We can work around this by
adjusting their limit. Note that `zipfile.writestr()` will not work
for strings larger than 2GiB. The Python interpreter sometimes rejects
strings that large (though it isn't clear to me exactly what
circumstances cause this). `zipfile.write()` must be used directly to
work around this.
This mess can be avoided if we port to python3.
The bug (b/19364241) in original commit has been fixed.
Bug: 18015246
Bug: 19364241
Bug: 19839468
(cherry picked from commit cd082d4bfe)
Change-Id: I7b5cc310e0a9ba894533b53cb998afd5ce96d8c6
BlockImageDiff has three versions. Only the incremental OTAs generated
with the latest version (3) can be re-applied to the system that's
already on the target build. Otherwise, operations like move will make
unconditional changes and damage the system. During the verification
phase, abort the OTA update if BlockImageDiff is less than 3 and it
doesn't match the checksum of the source build.
Change-Id: Ic630346eab2a993a84d0aeaacd7167ef62cc24f6
(cherry picked from commit daebaa6ed3)
This will only be used when the block file format is at least
version 3. For V1/V2 (L, L MR1) block versions, fall back to
the old range_sha1 check.
Bug: 19357591
Change-Id: I7cb178b70d48ec3c98cdb88ed1c94cf7797a01d0
(cherry picked from commit cad78c12fb)
BlockImageDiff has three versions. Only the incremental OTAs generated
with the latest version (3) can be re-applied to the system that's
already on the target build. Otherwise, operations like move will make
unconditional changes and damage the system. During the verification
phase, abort the OTA update if BlockImageDiff is less than 3 and it
doesn't match the checksum of the source build.
Change-Id: I3a776495b69e1d174fcb01b10e40c0e912914fd8
Add source and target block hashes as parameters to transfer list
commands that copy or patch data to a partition. This allows the
updater to verify the status of each command in the transfer list
and makes resuming block based OTAs possible. Due to the changes,
update the transfer list version to 3.
Needs matching changes from
I1e752464134aeb2d396946348e6041acabe13942
Bug: 18262110
Change-Id: Ia5c56379f570047f10f0aa7373a1025439495c98
(cherry picked from commit cac671a9d1)
Python 2.7's zipfile implementation wrongly thinks that zip64 is
required for files larger than 2GiB. We can work around this by
adjusting their limit. Note that `zipfile.writestr()` will not work
for strings larger than 2GiB. The Python interpreter sometimes rejects
strings that large (though it isn't clear to me exactly what
circumstances cause this). `zipfile.write()` must be used directly to
work around this.
This mess can be avoided if we port to python3.
Bug: 18015246
Change-Id: I8a476d99c5efdef6ea408373b706e9fbd3a798be
Add source and target block hashes as parameters to transfer list
commands that copy or patch data to a partition. This allows the
updater to verify the status of each command in the transfer list
and makes resuming block based OTAs possible. Due to the changes,
update the transfer list version to 3.
Needs matching changes from
I1e752464134aeb2d396946348e6041acabe13942
Bug: 18262110
Change-Id: Ia5c56379f570047f10f0aa7373a1025439495c98
Change boot, recovery, and verity metadata signing keys to use the
same PKCS8 / X.509 PEM format as the other signing keys, and update
build scripts to use correct arguments for the updated signing
tools.
Bug: 15984840
Bug: 18120110
Change-Id: I23ed5a004ecdad6cf7696487935ad5031eb8adf8
(cherry picked from commit 72d90eb189)
Generate version 2 of the block_image_update transfer list format.
This improves patch size by a different strategy for dealing with
out-of-order transfers. If transfer A must be done before transfer B
due to B overwriting A's source but we want to do B before A, we
resolve the conflict by:
- before B is executed, we save ("stash") the overlapping region (ie
the blocks B will overwrite that A wants to read)
- when A is executed, it will read those parts of source data from
the stash rather than from the image.
This reverses the ordering constraint; with these additions now B
*must* go before A. The implementation of the stash is left up to the
code that executes the transfer list to apply the patch; it could hold
stashed data in RAM or on a scratch disk such as /cache, if available.
The code retains the ability to build a version 1 block image patch;
it's needed for processing older target-files.
Change-Id: Ia9aa0bd45d5dc3ef7c5835e483b1b2ead10135fe
When generating incrementals for the system and vendor partitions,
check the first block (which contains the superblock) of the partition
to see if it's what we expect. If this check fails, give an explicit
log message about the partition having been remounted R/W (the most
likely explanation) and the need to flash to get OTAs working again.
Bug: 17393999
Change-Id: Ifd2132b428dbc4907527291712690204a3664ac0
Move BlockDifference into common and make its script generation code
more complete, so that it can be use by releasetools.py to do diffs on
baseband images.
Bug: 16984795
Change-Id: Iba9afc1c7755458ce47468b5170672612b2cb4b3
Replace the xdelta/xz-based block OTA generation with a new system
based on the existing bsdiff/imgdiff tools.
Bug: 16984795
Change-Id: Ia9732516ffdfc12be86260b2cc4b1dd2d210e886
Now that we're building and saving images in the target_files at build
time, we should use those images instead of rebuilding them.
Bug: 17201052
Change-Id: I459e650f66f1e0bdf01ad54df9e34f36bf2ee899
This ensures that when the verity key is rotated to a release key
both the boot and recovery images will be correctly signed. It does
mean that they will both be signed with the same key for now, but
as that doesn't change the threat model separating them is just a
distant nice-to-have.
Bug: 15725238
Change-Id: I5b75e4346fe0655065643ab553431690cc1a8cb0
The AOSP bootimage format allows the use of a second stage image
however the BuildBootableImage function does not allows the "second"
optional argument. This patch adds the support of this argument.
Bug: 17035158
Change-Id: I8ed9d9e56449945c2d42fc908269921c394f68c0
Signed-off-by: Benoit Fradin <benoit.fradin@intel.com>
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Signed-off-by: Patrick Tjin <pattjin@google.com>
When making bsdiff/imgdiff patches, give up after 5 minutes. (On
certain large files it can take hours to build a patch, if it ever
even completes.)
Change-Id: I123c06f8194f85f6f4e640f7eb31c7746f76ba4d
