On Tue, Mar 12, 2024 at 04:00:02PM +0800, Yong Huang wrote: > On Tue, Mar 12, 2024 at 3:28 PM Gary Lin <g...@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