All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: James Bottomley <jejb@linux.ibm.com>
Cc: grub-devel@gnu.org, dovmurik@linux.vnet.ibm.com,
	Dov.Murik1@il.ibm.com, ashish.kalra@amd.com,
	brijesh.singh@amd.com, tobin@ibm.com, david.kaplan@amd.com,
	jon.grimm@amd.com, thomas.lendacky@amd.com, frankeh@us.ibm.com
Subject: Re: [PATCH 0/3] Add ability to use SEV provisioned secrets for disk decryption
Date: Fri, 13 Nov 2020 17:50:15 +0000	[thread overview]
Message-ID: <20201113175015.GS3251@work-vm> (raw)
In-Reply-To: <20201113012206.24246-1-jejb@linux.ibm.com>

* James Bottomley (jejb@linux.ibm.com) wrote:
> To achieve encrypted disk images in the AMD SEV encrypted virtual
> machine, we need to add the ability for grub to retrieve the disk
> passphrase from the SEV launch secret.  To do this, we've modified
> OVMF to set aside an area for the injected secret and pass up a
> configuration table for it:
> 
> https://edk2.groups.io/g/devel/topic/78198617#67339
> 
> The patches in this series modify grub to look for the disk passphrase
> in the secret configuration table and use it to decrypt any disks in
> the system if they are found.  This is so an encrypted image with a
> properly injected password will boot without any user intervention.
> 
> The three patches firstly modify the cryptodisk consumers to allow
> arbitrary password getters instead of the current console based one.
> The next patch adds a '-s' option to cryptodisk to allow it to use a
> saved password and the final one adds a sevsecret command to check for
> the secrets configuration table and provision the disk passphrase from
> it if an entry is found.  With all this in place, the sequence to boot
> an encrypted volume without user intervention is:
> 
> sevsecret
> cryptomount -s
> source (crypto0)/boot/grub.cfg

I was thinking what happens if the evil admin adds an extra disc; I
guess the argument here is that:
  a) Since you specify (crypto0) it can only be a decrypted disc
  b) And since only the guest owner can supply the keys, it can only be
there disc image that can be decrypted.

Right?

Dave

> Assuming there's a standard Linux root partition.
> 
> James
> 
> ---
> 
> James Bottomley (3):
>   cryptodisk: make the password getter and additional argument to
>     recover_key
>   cryptodisk: add OS provided secret support
>   efi: Add API for retrieving the AMD SEV injected secret for cryptodisk
> 
>  grub-core/Makefile.core.def    |   8 +++
>  grub-core/disk/cryptodisk.c    |  60 +++++++++++++++--
>  grub-core/disk/efi/sevsecret.c | 118 +++++++++++++++++++++++++++++++++
>  grub-core/disk/geli.c          |   5 +-
>  grub-core/disk/luks.c          |  12 ++--
>  grub-core/disk/luks2.c         |  12 ++--
>  include/grub/cryptodisk.h      |   8 ++-
>  include/grub/efi/api.h         |  15 +++++
>  8 files changed, 221 insertions(+), 17 deletions(-)
>  create mode 100644 grub-core/disk/efi/sevsecret.c
> 
> -- 
> 2.26.2
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK



  parent reply	other threads:[~2020-11-13 18:18 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-13  1:22 [PATCH 0/3] Add ability to use SEV provisioned secrets for disk decryption James Bottomley
2020-11-13  1:22 ` [PATCH 1/3] cryptodisk: make the password getter and additional argument to recover_key James Bottomley
2020-11-13  6:02   ` Glenn Washburn
2020-11-13 15:44     ` James Bottomley
2020-11-13  1:22 ` [PATCH 2/3] cryptodisk: add OS provided secret support James Bottomley
2020-11-13 13:23   ` Dr. David Alan Gilbert
2020-11-13 15:49     ` James Bottomley
2020-11-13  1:22 ` [PATCH 3/3] efi: Add API for retrieving the AMD SEV injected secret for cryptodisk James Bottomley
2020-11-13 17:50 ` Dr. David Alan Gilbert [this message]
2020-11-13 17:58   ` [PATCH 0/3] Add ability to use SEV provisioned secrets for disk decryption James Bottomley
2020-11-13 18:21     ` Dr. David Alan Gilbert
2020-11-13 19:26       ` James Bottomley

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=20201113175015.GS3251@work-vm \
    --to=dgilbert@redhat.com \
    --cc=Dov.Murik1@il.ibm.com \
    --cc=ashish.kalra@amd.com \
    --cc=brijesh.singh@amd.com \
    --cc=david.kaplan@amd.com \
    --cc=dovmurik@linux.vnet.ibm.com \
    --cc=frankeh@us.ibm.com \
    --cc=grub-devel@gnu.org \
    --cc=jejb@linux.ibm.com \
    --cc=jon.grimm@amd.com \
    --cc=thomas.lendacky@amd.com \
    --cc=tobin@ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.