grub-devel.gnu.org archive mirror
 help / color / mirror / Atom feed
From: Gary Lin via Grub-devel <grub-devel@gnu.org>
To: Yong Huang <yong.huang@smartx.com>
Cc: Gary Lin <glin@suse.com>,
	The development of GNU GRUB <grub-devel@gnu.org>,
	James Bottomley <jejb@linux.ibm.com>
Subject: Re: [PATCH RFC 0/2] use confidential computing provisioned secrets for disk decryption
Date: Tue, 12 Mar 2024 16:41:44 +0800	[thread overview]
Message-ID: <20240312084144.hrrfsnlwuop2rskr@GaryLaptop> (raw)
In-Reply-To: <CAK9dgmbbDaFfNBax6+1MOrjD=Fds3S_zG+Z+iOhjokVc_b29RA@mail.gmail.com>

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

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

      reply	other threads:[~2024-03-12  8:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-12  3:03 [PATCH RFC 0/2] use confidential computing provisioned secrets for disk decryption Hyman Huang
2024-03-12  3:03 ` [PATCH RFC 1/2] cryptodisk: add OS provided secret support Hyman Huang
2024-03-12  3:03 ` [PATCH RFC 2/2] efi: Add API for retrieving the EFI secret for cryptodisk Hyman Huang
2024-03-12  7:28 ` [PATCH RFC 0/2] use confidential computing provisioned secrets for disk decryption Gary Lin via Grub-devel
2024-03-12  8:00   ` Yong Huang
2024-03-12  8:41     ` Gary Lin via Grub-devel [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240312084144.hrrfsnlwuop2rskr@GaryLaptop \
    --to=grub-devel@gnu.org \
    --cc=glin@suse.com \
    --cc=jejb@linux.ibm.com \
    --cc=yong.huang@smartx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).