No device_path information when extending PCR4 done by shim_verify
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
Start by tracing the shim_verify() communication path and the tpm_log_pe() call mentioned in the issue, focusing on where DevicePath information could be passed to the TPM event log. Review the proposed shim_verify2() mechanism and related discussion before defining the API. Done means a kernel PCR4 extension produces an EV_EFI_BOOT_SERVICES_APPLICATION event containing the correct DevicePath without relying on pathless extensions.
Written by the indexing model from the issue text.
Description
When secure boot gets enabled we found that the TPM2 event log does not contain the "DevicePath" information related to the EV_EFI_BOOT_SERVICES_APPLICATION event during the PCR 4 extension for the kernel.
After some debugging (see cc) the cause seems to be that the communication between systemd-boot and shim is done via shim_verify(), that does not accept any "DevicePath" information that can be later be communicated to tpm_log_pe()
This is an issue because some tools, like pcr-oracle use the "DevicePath" form the event log to locate the PE binary and do a rehash to calculate new predictions and policies. The proposed workaround is very brittle and will be invalidated if more that one pathless extension happens in PCR4, so we are looking for a more robust solution.
Do makes sense to have a shim_verify2() or some other mechanism that can be used to pass the device path information?
cc: @lnussel, @arvidjaar
- Dominant language
- C
- Stars
- 1.1k
- Forks
- 348
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from rhboot/shim
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
-
Difficulty 4/5 3-5 days Newbie friendliness 38/100
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
Difficulty 4/5 3-5 days Newbie friendliness 42/100
-
Difficulty 4/5 3-5 days Newbie friendliness 55/100
Similar issues
-
[adam] AdamNet network read doesn't cap to MAX_ADAM_PACKET_LEN, overflows client receive buffers Open
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
FujiNetWIFI/fujinet-firmware#1649 · 2 comments ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
HarbourMasters/Shipwright#7229 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
riscv-software-src/riscv-isa-sim#2435 · 1 comment ·
-
bug Self Built Image SNAPSHOT Supported Device target/ramips
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100