CVE-2024-29779 AI-generated analysis
platform/system/keymint, wire crate (legacy Trusty Keymaster message classification, wire/src/legacy.rs)
Adds the SetAttestationIdsKM3 (0xc001) legacy Trusty Keymaster message to the is_trusty_provisioning_code and is_trusty_provisioning_req predicates in platform/system/keymint wire/src/legacy.rs, so it is classified as a provisioning request like SetAttestationIds (0xc000).
Root cause
The TrustyKeymasterOperation enum in wire/src/legacy.rs (non-secure port) defines two attestation-ID messages: SetAttestationIds = 0xc000 and SetAttestationIdsKM3 = 0xc001. The predicates is_trusty_provisioning_code(code) and is_trusty_provisioning_req(req) listed SetAttestationKey, AppendAttestationCertChain, ClearAttestationCertChain, SetWrappedAttestationKey and SetAttestationIds, but not SetAttestationIdsKM3. As a result, a SetAttestationIdsKM3 message was not reported as a provisioning message by either predicate.
How the fix works
- wire/src/legacy.rs:is_trusty_provisioning_code: adds `| Some(TrustyKeymasterOperation::SetAttestationIdsKM3)` to the matches! pattern, so raw opcode 0xc001 is now reported as a provisioning code.
- wire/src/legacy.rs:is_trusty_provisioning_req: adds `| TrustyPerformOpReq::SetAttestationIdsKM3(_)` to the matches! pattern, so a decoded SetAttestationIdsKM3 request is now reported as a provisioning request.
- wire/src/legacy.rs:declare_req_rsp_enums!(TrustyKeymasterOperation): adds a comment and blank lines that group the provisioning-related variants (0x2000 to 0xc001) and note that changes there must be reflected in is_trusty_provisioning_{code,req}. The enum itself does not change functionally.
- Single commit, 5 added lines, no change for any other opcode. Test named in the commit message: trusty_keymaster_set_attestation_ids.
Completeness
- Both predicates that classify non-secure-port legacy messages (one by raw code, one by decoded request) are updated consistently. Every variant in the provisioning group of TrustyKeymasterOperation (0x2000, 0x3000, 0xa000, 0xb000, 0xc000, 0xc001) is now covered.
- The fix only changes classification. The material does not show any enforcement code that uses is_trusty_provisioning_* (the index search found no callers), so it cannot be judged whether all relevant paths call these predicates.
- The secure-port enum TrustyKeymasterSecureOperation (SetAttestationIds = 0xc000) and CuttlefishKeymasterOperation (SetAttestationIds = 38) are untouched. The material shows no provisioning predicate for them and no KM3 variant in them.
- matches! is not exhaustive, so the added comment is the only safeguard against the same omission when new provisioning opcodes are added.
Behavior changes
- is_trusty_provisioning_code(0xc001) now returns true (previously false).
- is_trusty_provisioning_req on TrustyPerformOpReq::SetAttestationIdsKM3 now returns true (previously false).
- Any caller that relies on these predicates will now treat SetAttestationIdsKM3 as a provisioning message. The callers and what they do are not shown in the material. No other opcode is affected.
Per major
- Android 14: same fix: commit 1f6bf0cae40c (cherry-pick, Ignore-AOSP-First) in android-security-14.0.0_r14. All 8 lines of the patched region are present at android-security-14.0.0_r29.
- Android 15: not affected (per the bulletin). The patched region is present (8/8 lines) at android-security-15.0.0_r17.
- Android 16: not affected (per the bulletin). The patched region is present (8/8 lines) at android-security-16.0.0_r8.
- Android 17: not affected (per the bulletin). The patched region is present (8/8 lines) at android-security-17.0.0_r1.
Unknowns
- Which code uses is_trusty_provisioning_code / is_trusty_provisioning_req and what restriction it enforces. Neither the material nor the index results show this.
- What SetAttestationIdsKM3Request contains compared with SetAttestationIdsRequest.
- How SetAttestationIdsKM3 messages reach the non-secure port on affected devices, and from which privilege level.
- The content of the test trusty_keymaster_set_attestation_ids.