Re: [PATCH RFC 0/2] use confidential computing provisioned secrets for disk decryption

[Gary Lin]

On Tue, Mar 12, 2024 at 04:00:02PM +0800, Yong Huang wrote:
> On Tue, Mar 12, 2024 at 3:28 PM Gary Lin <glin@suse.com> wrote:
> 
> > On Tue, Mar 12, 2024 at 11:03:17AM +0800, Hyman Huang wrote:
> > Hi Hyman,
> >
> > > This patchset aims to supplement James's previous work, please refer to
> > > the following link for details:
> > > https://lists.gnu.org/archive/html/grub-devel/2020-12/msg00257.html
> > >
> > > The alterations listed below were made in light of earlier research:
> > > 1. As Glenn advised, remove the first commit ([PATCH v3 1/3] cryptodisk:
> > >    make the password getter and additional argument to recover_key) while
> > >    maintaining the original recover key function declaration.
> > >
> > > 2. To decrypt the disk, use the password that was retrieved from the EFI
> > >    secret area and store it in the key_data field of the
> > >    grub_cryptomount_args_t. Then, pass the password to the
> > >    grub_cryptodisk_scan_device function.
> > >
> > > 3. Modify the put method's function definition in struct
> > >    grub_secret_entry, and use grub_errno to log method errors.
> > >
> > > We uploaded this series with the intention of receiving feedback, as
> > > the title suggests. Any suggestions and feedback regarding this patchset
> > > are welcom.
> > >
> > I'm working on disk unlocking with TPM2 and it's a bit similar to your
> > work. Here is my v9 patchset:
> > https://lists.gnu.org/archive/html/grub-devel/2024-02/msg00007.html
> >
> > The original patch author, Herman, introduced the key protectors
> > framework, and it may be useful in your case:
> >
> I take it that the AMD SEV secret inject can be implemented using
> the key protector framework feature once it's ready?
> 
That's my first impression. The key protector framework goes through the
registered list and provides the password from the specified protector,
and it looks similar to your patch.

> >
> > - key protectors framework
> >   https://lists.gnu.org/archive/html/grub-devel/2024-02/msg00014.html
> > - cryptodisk change
> >   https://lists.gnu.org/archive/html/grub-devel/2024-02/msg00016.html
> 
> 
> So, Should I post version 2 and rebase on the patchset then?
> 
If you find it's reasonable to use the key protector framework, then yes :)

Thanks,

Gary Lin

> 
> >
> > - TPM2 key protector
> >   https://lists.gnu.org/archive/html/grub-devel/2024-02/msg00017.html
> >
> > In short, it unlocks the disk with the commands like this:
> >
> >   tpm2_key_protector_init --tpm2key=(hd0,gpt1)/efi/grub2/sealed-1.tpm
> >   cryptomount -u <PART1_UUID> -P tpm2
> >
> > Maybe we can work together to support various disk unlocking mechanisms.
> >
> 
> Sure, of course, yes.
> 
> 
> > Cheers,
> >
> > Gary Lin
> >
> > > Thanks,
> > >
> > > Yong
> > >
> > > Hyman Huang (2):
> > >   cryptodisk: add OS provided secret support
> > >   efi: Add API for retrieving the EFI secret for cryptodisk
> > >
> > >  grub-core/Makefile.core.def    |   8 +++
> > >  grub-core/disk/cryptodisk.c    |  49 ++++++++++++-
> > >  grub-core/disk/efi/efisecret.c | 123 +++++++++++++++++++++++++++++++++
> > >  include/grub/cryptodisk.h      |  14 ++++
> > >  include/grub/efi/api.h         |  15 ++++
> > >  5 files changed, 206 insertions(+), 3 deletions(-)
> > >  create mode 100644 grub-core/disk/efi/efisecret.c
> > >
> > > --
> > > 2.39.3
> > >
> > >
> > > _______________________________________________
> > > Grub-devel mailing list
> > > Grub-devel@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/grub-devel
> >
> 
> Thanks for the comments, :)
> 
> Yong
> 
> -- 
> Best regards