On 2024-03-27 17:38, Andrei Borzenkov wrote:
On 27.03.2024 20:26, aplanas wrote:
I can prepare an update to sdbootutil that will do the migration from pcr-oracle to pcrlock, or at least I will document how it can be done manually (is as simple as removing the tpm2-* files from the ESP and /var and calling `sdbootutil update-predictions`)
You mean - after sdbootutil has been updated?
Yes. The new sdbootutil contains now a set of calls to pcrlock, that will generate the predictions. For that will check before that is not already a signed policy systemd (pcr-oracle). So removing the files will now generate the .pcrlock files and insert in the TPM2 the policy.
Is systemd-pcrlock affected by https://bugzilla.suse.com/show_bug.cgi?id=1219807?
The one about secure boot was fixed (workaround really) in an already release of pcr-oracle, so the current user should not experience the original bug. Do you still experience this one? But about your question: no, pcrlock uses a different mechanism to guess the meaning of an extension in the event log. With pcr-oracle we use the tags and the data of the event to guess what that means (so the error is that shim removes part of this data), but pcrlock use the components and variants that contain the hash. If pcrlock find the hash in the event log in one of those components or variants, the bijection is done. You can validate this mapping with systemd-pcrlock itself as it will indicate what .pcrlock file has this hash (or at least one of the variants)