On Fri, Sep 20, 2024 at 09:42:01AM -0400, Stefan Berger wrote:
>
Sorry for my late reply. Just back from vacation.
>
> On 9/20/24 4:16 AM, Gary Lin wrote:
> > On Fri, Sep 13, 2024 at 10:25:14AM -0400, Stefan Berger wrote:
> > >
> > >
>
> > > > +SHA1, SHA256, SHA384, and SHA512, and the default is SHA256.
> > > > +
> > > > +There are some options only available for the specific mode. The
> > > > SRK-specific
> > > > +options are @option{-T}, @option{-k}, @option{-a}, and @option{-s}. On
> > > > the
> > > > +other hand, the NV index-specific option is @option{-n}.
> > > > +
> > > > +The key file for SRK mode can be supplied with either @option{-T} or
> > > > +@option{-k}. The @option{-T} option is for the path to the key file in
> > > > +the TPM 2.0 Key File format. Since the parameters for the TPM commands
> > > > are
> > > > +written in the policy sequences, there is no need to set the PCR
> > >
> > > What is 'the policy sequences' ?
> > >
> > It's the TPMPolicy sequence which contains the command code and the
> > parameters.
>
> So sequence is an ASN.1 sequence? 0x30 iirc. I think people will have a hard
> time understanding this. You have to describe this in some other way without
> the word 'policy sequence'.
>
I'm considering to replace 'policy sequence' with 'file'.
> >
> > https://www.hansenpartnership.com/draft-bottomley-tpm2-keys.html#name-tpmpolicy-syntax
>
>
> > > When I looked through the patches I did not see anything particularly
> > > related to EFI. Is it only available on EFI and EMU platforms because you
> > > did not test it with a (Sea)BIOS for example ? I was actually going to try
> > > it on PPC64 on KVM that has SLOF firmware.
> > >
> > It's related to the tcg2 functions defined in grub-core/lib/tss2/tcg2.h.
> > Currently, there is only two implementations:
> >
> > EFI: grub-core/lib/efi/tcg2.c
> > EMU: grub-core/lib/tss2/tcg2_emu.c
>
> Right. I have a version of ieee1275 powerpc now.
>
> >
> > > > +reads the TPM eventlog and predicts the PCR values. Besides,
> > > > +@command{pcr-oracle} also supports ``authorized policy'' which allows
> > > > the
> > > > +PCR policy to be updated with a valid signature, so that the user only
> > > > +needs to seal the random disk key once and then updates the signature
> > > > +of PCR policy for the later changes.
> > >
> > > ... and then the user needs to update the signature of the PCR policy for
> > > the later changes. (?)
> > >
> > > I am not sure what this means though in practice.
> > >
> > The random disk key is first sealed with the user's public key, and then
> > the user signs the 'policy', i.e. the hash of the PCR hashes, and
> > appends the signature into the key file as the parameter for
> > TPM2_PolicyAuthorize. For the later PCR changes, the user only
> > needs to sign the new policy and update the signature.
> >
> > https://www.hansenpartnership.com/draft-bottomley-tpm2-keys.html#name-tpm2_policyauthorize
> >
> > How about rewriting the paragragh like this:
> >
> > @command{pcr-oracle} also supports ``authorized policy'' which allows the
> > PCR policy to be updated with a valid signature, so that the user only seals
> > the random disk key once. For the later changes, the user just needs to
> > update the signature of PCR policy.
>
> You have to describe what you mean with 'the later changes'. Something like
> this maybe:
>
> If at some later time the PCR values change due to an updated of the
> system's firmware, the user just need to ... ??
It includes whatever changes to PCRs such as firmware update, bootloader
update, or config file update, so I'd extend the statement a bit:
If at some later time the PCR values change due to an update of the
system firmware, bootloader, or config file, the user just needs to ...
Gary Lin
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
