Re: PCR signing / enrolling on UKI and validation by systemd-cryptenroll

[Andrei Borzenkov <arvidjaar@xxxxxxxxx>]

On Mon, May 27, 2024 at 11:17 AM Lennart Poettering
<lennart@xxxxxxxxxxxxxx> wrote:
>
> On Sa, 25.05.24 13:23, Andrei Borzenkov (arvidjaar@xxxxxxxxx) wrote:
>
> > These are PCRs for which you intend to provide signed policy. These PCRs
> > must be listed in JSON file that is given to systemd-cryptsetup as
> > tpm2-signature= parameter. The only PCR for which there is systemd tool to
> > compute it is PCR 11. You should be able to add other PCRs to this JSON file
> > and it should work, but you will need to compute the values yourself.
> >
> > Unfortunately, this is yet another case where systemd pretends to be generic
> > while in reality it is not.
>
> Hmm, where do we pretend anything?
>

By allowing users to specify different PCRs than PCR 11 without
providing any way to actually provide necessary information in the
format that is expected. Or documenting this format if the answer is
"you need to do it yourself".

If the only PCR that can be practically used is PCR 11 anyway, then
--tpm2-public-key-pcrs= is simply redundant and confusing.

> We give you a tool to predict/sign the measurements for PCR 11 because
> we can just do that from the UKI. For other PCRs it's a very different
> story however.
>

That is exactly what I mean. The whole implementation of signed policy
was done for UKI only but the documentation looks like it is generic.

Nobody demands a tool to predict PCR values. But if I do have PCR
values, there is no tool to pack them into tpm2-pcr-signature.json.

> (And we do provide a tool for that too nowadays btw, i.e. systemd-pcrlock).
>

That is a different story altogether. It is much better than raw PCR
policy for local use, but signed policy allows centrally managing
trusted values. If there is a way to tell systemd-pcrlock to only
accept PCR values coming from the trusted source I missed it.