Each CompOS VM (pending or current) will need an instance file.
Add checking/use of these to odsign.
I now believe it never makes sense for odsign to attempt to generate a
new CompOS keypair; CompOS can do that itself when appropriate. So
remove a bunch of code related to that (it's been re-implemented in
CompOS in Rust anyway).
FakeCompOs now takes an instance file parameter, although only the
real CompOS will do anything with it.
Move all the instance & key files to
/data/misc/apexdata/com.android.compos, since CompOS should own them.
More refactoring & general tinkering.
This is all still behind "if (false)", but we're getting closer to
removing that.
Fix: 194654666
Test: Manual: Pending but no current instance; pending and current;
Test: current only with and without cert; no instances but valid cert;
Test: no compos files at all; invalid pending keys;
Test: invalid current keys.
Change-Id: Ie92ba414415b237512621c76c647640508f4b1e6
If odsign is marked as oneshot, and it crashes (eg due to a coding
error), the device will not boot completely, because init keeps waiting
for the odsign.key.done / odsign.verification.done properties. So
instead, we don't mark it as oneshot, but stop the service manually in
the exit paths of the code. This ensures that if a bad OTA / module
update causes odsign to crash, we will automatically start it again; if
it crashes repeatedly, apexd will detect this, and roll back any module
update.
In the good path, there's no difference - odsign will run just once and
be stopped.
Bug: 194334176
Test: manually make odsign crash; inspect output
Change-Id: I7015f291888d6b8066e4c526a7e8cf3c9c7ea618
Merged-In: I7015f291888d6b8066e4c526a7e8cf3c9c7ea618
If odsign is marked as oneshot, and it crashes (eg due to a coding
error), the device will not boot completely, because init keeps waiting
for the odsign.key.done / odsign.verification.done properties. So
instead, we don't mark it as oneshot, but stop the service manually in
the exit paths of the code. This ensures that if a bad OTA / module
update causes odsign to crash, we will automatically start it again; if
it crashes repeatedly, apexd will detect this, and roll back any module
update.
In the good path, there's no difference - odsign will run just once and
be stopped.
Bug: 194334176
Test: manually make odsign crash; inspect output
Change-Id: I7015f291888d6b8066e4c526a7e8cf3c9c7ea618
When using the rkp_factory_extraction_tool in test mode, a fake device
key is generated on the fly. This makes verifying the output difficult
as the key is permanently lost.
In test mode, print out the generated keys so that we can test if the
output data is good or not.
Test: Manually tested against backend service tooling not in AOSP
Change-Id: Ibc30044c03f5107990da6d3a03b17aa652d4b1bc
The ndk_platform backend will soon be deprecated because the ndk backend
can serve the same purpose. This is to eliminate the confusion about
having two variants (ndk and ndk_platform) for the same 'ndk' backend.
Bug: 161456198
Test: m
Change-Id: Ibeb4178f99857be75bb5f83a073a2d679058d921
The number of times I've said "Oh yeah, I'll put a change in later to
add myself to OWNERS" has become embarassing.
Test: I can give OWNERS +2
Change-Id: If24b192fe0f2ca65f6cac58602c0b2b63f2df094
1. The MAC tag value was not being included in the uploaded data, so
it was previosly impossible to verify the keys to sign mac.
2. The device info is supposed to be an array with [Verified,
Unverified] info. It was previously just the verified info.
Ignore-AOSP-First: No merge path from AOSP. This is picked from AOSP.
Test: Manual. Uploaded sample data to device info service.
Change-Id: I096bc5ded0b38fc56864e75c5e06dfbef62e9a74
Merged-In: I096bc5ded0b38fc56864e75c5e06dfbef62e9a74
Fixes: 194492359
1. The MAC tag value was not being included in the uploaded data, so
it was previosly impossible to verify the keys to sign mac.
2. The device info is supposed to be an array with [Verified,
Unverified] info. It was previously just the verified info.
Test: Manual. Uploaded sample data to device info service.
Change-Id: I096bc5ded0b38fc56864e75c5e06dfbef62e9a74
Bug: 194492359
