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
passed in argument to recover_key() makes
this possible.
Signed-off-by: James Bottomley
---
grub-core/disk/cryptodisk.c | 2 +-
grub-core/disk/geli.c | 5 +++--
grub-core/disk/luks.c | 12 +++-
grub-core/disk/luks2.c | 12 +++-
include/grub/cryptodisk.h | 6
large numbers of
iterations, use a base64 encoding of 33 bytes of random data.
Signed-off-by: James Bottomley
---
grub-core/Makefile.core.def| 8 +++
grub-core/disk/efi/sevsecret.c | 118 +
include/grub/efi/api.h | 15 +
3 files changed, 141 inser
al machine. OVMF
provides the secret area and passes it into the EFI Configuration
Tables. The grub EFI layer pulls the secret out and primes the
secrets API with it. The upshot of all of this is that a SEV
protected VM can do an encrypted boot with a protected boot secret.
Signed-off-by: James
On Fri, 2020-11-13 at 00:02 -0600, Glenn Washburn wrote:
[...]
> diff --git a/grub-core/disk/geli.c b/grub-core/disk/geli.c
> > index e9d23299a..5514c16a3 100644
> > --- a/grub-core/disk/geli.c
> > +++ b/grub-core/disk/geli.c
> > @@ -398,7 +398,8 @@ configure_ciphers (grub_disk_t disk, const char
>
On Fri, 2020-11-13 at 13:23 +, Dr. David Alan Gilbert wrote:
> * James Bottomley (j...@linux.ibm.com) wrote:
[...]
> > @@ -1117,11 +1151,28 @@ grub_cmd_cryptomount (grub_extcmd_context_t
> > ctxt, int argc, char **args)
> >else if (state[1].set || (argc
On Fri, 2020-11-13 at 17:50 +, Dr. David Alan Gilbert wrote:
> * James Bottomley (j...@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
On Fri, 2020-11-13 at 18:21 +, Dr. David Alan Gilbert wrote:
> * James Bottomley (j...@linux.ibm.com) wrote:
> > On Fri, 2020-11-13 at 17:50 +, Dr. David Alan Gilbert wrote:
> > > * James Bottomley (j...@linux.ibm.com) wrote:
> > > > To achieve encryp
me without user intervention is:
sevsecret
cryptomount -s
source (crypto0)/boot/grub.cfg
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 suppor
passed in argument to recover_key() makes
this possible.
Signed-off-by: James Bottomley
---
v2: add conditional prompting to geli.c
---
grub-core/disk/cryptodisk.c | 2 +-
grub-core/disk/geli.c | 12 +++-
grub-core/disk/luks.c | 12 +++-
grub-core/disk/luks2.c
al machine. OVMF
provides the secret area and passes it into the EFI Configuration
Tables. The grub EFI layer pulls the secret out and primes the
secrets API with it. The upshot of all of this is that a SEV
protected VM can do an encrypted boot with a protected boot secret.
Signed-off-by: James
large numbers of
iterations, use a base64 encoding of 33 bytes of random data.
Signed-off-by: James Bottomley
---
v2: use callback to print failure message and destroy secret
---
grub-core/Makefile.core.def| 8 ++
grub-core/disk/efi/sevsecret.c | 132 +
in
On Fri, 2020-11-13 at 19:50 -0600, Glenn Washburn wrote:
> On Fri, 13 Nov 2020 14:25:07 -0800
> James Bottomley wrote:
>
> > v2: update geli.c to use conditional prompt and add callback for
> > variable message printing and secret destruction
> >
> > To ach
t/grub.cfg
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 EFI secret for cryptodisk
grub-core/Ma
passed in argument to recover_key() makes
this possible.
Signed-off-by: James Bottomley
---
v2: add conditional prompting to geli.c
v3: make getter specify prompt requirement
---
grub-core/disk/cryptodisk.c| 2 +-
grub-core/disk/geli.c | 12 +++-
grub-core/disk
al machine. OVMF
provides the secret area and passes it into the EFI Configuration
Tables. The grub EFI layer pulls the secret out and primes the
secrets API with it. The upshot of all of this is that a SEV
protected VM can do an encrypted boot with a protected boot secret.
Signed-off-by: James
need large numbers of
iterations, use a base64 encoding of 33 bytes of random data.
Signed-off-by: James Bottomley
---
v2: use callback to print failure message and destroy secret
v3: change to generic naming to use for TDX and SEV and use new mechanism
---
grub-core/Makefile.core.def
On Thu, 2020-12-31 at 21:42 +0300, Dmitry wrote:
[...]
> > --- a/grub-core/disk/luks2.c
> > +++ b/grub-core/disk/luks2.c
> > @@ -542,7 +542,8 @@ luks2_decrypt_key (grub_uint8_t *out_key,
> >
> > static grub_err_t
> > luks2_recover_key (grub_disk_t source,
> > - grub_cryptodisk_t
On Sat, 2021-01-02 at 19:45 -0600, Glenn Washburn wrote:
> James,
>
> I like the improvements here. However, I've been thinking more about
> this and other improvements that deal with passing parameters to
> modules used by cryptomount. I have some ideas that I've not had the
> time to fully inves
On Tue, 2021-01-05 at 14:03 -0600, Glenn Washburn wrote:
> On Mon, 04 Jan 2021 22:48:49 -0800
> James Bottomley wrote:
>
> > On Sat, 2021-01-02 at 19:45 -0600, Glenn Washburn wrote:
> > > James,
> > >
> > > I like the improvements here. However, I&
On Sun, 2021-01-03 at 12:46 +0200, Dov Murik wrote:
> Hello James,
>
> On 31/12/2020 19:36, James Bottomley wrote:
[...]
> > diff --git a/grub-core/disk/efi/efisecret.c b/grub-
> > core/disk/efi/efisecret.c
> > new file mode 100644
> > index 0..318af0784
On Thu, 2021-02-11 at 23:50 -0500, Eli Schwartz wrote:
[...]
> It would probably make more sense to use a patchwork configured to
> run CI on incoming patches, and maybe even respond to the mailing
> list with status reports.
>
> e.g.
>
> https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/20108
>
>
On Sun, 2021-02-28 at 00:05 +0100, Javier Martinez Canillas wrote:
> Currently if an EFI firmware fails to do a TPM measurement for a
> file, the error will be propagated to the verifiers framework which
> will prevent it to be opened.
>
> This mean that buggy firmwares will lead to the system not
On Sun, 2021-02-28 at 18:58 +0100, Javier Martinez Canillas wrote:
> [re-sending since I got a 'Recipient server unavailable or busy'
> error, sorry if someone gets this email twice]
>
> Hello James,
>
> On 2/28/21 8:10 AM, James Bottomley wrote:
> > On Sun,
On Sun, 2021-02-28 at 23:42 +0100, Javier Martinez Canillas wrote:
> On 2/28/21 7:25 PM, James Bottomley wrote:
> > On Sun, 2021-02-28 at 18:58 +0100, Javier Martinez Canillas wrote:
>
> [snip]
>
> > > I don't see how that would be the case. For anyone doing mea
On Wed, 2021-03-03 at 18:28 +0100, Daniel Kiper wrote:
> On Sun, Feb 28, 2021 at 03:25:04PM -0800, James Bottomley wrote:
>
> [...]
>
> > How about a more simple solution: you sign two grub unitary EFI
> > binaries, one of which does measured boot and one of which doesn&
On Mon, 2021-03-22 at 15:19 -0500, Glenn Washburn wrote:
> On Mon, 22 Mar 2021 16:16:26 +
> Colin Watson wrote:
>
> > On Mon, Mar 22, 2021 at 04:20:00PM +0100, Daniel Kiper wrote:
> > > NAK for this patch and others "fixing" small MBR gaps. I am not
> > > going to deal with this kind of issue
From: James Bottomley
v3: make password getter specify prompt requirement. Update for TDX:
Make name more generic and expand size of secret area
https://github.com/tianocore/edk2/commit/96201ae7bf97c3a2c0ef386110bb93d25e9af1ba
https://github.com/tianocore/edk2/commit
al machine. OVMF
provides the secret area and passes it into the EFI Configuration
Tables. The grub EFI layer pulls the secret out and primes the
secrets API with it. The upshot of all of this is that a SEV
protected VM can do an encrypted boot with a protected boot secret.
Signed-off-by: James
need large numbers of
iterations, use a base64 encoding of 33 bytes of random data.
Signed-off-by: James Bottomley
---
v2: use callback to print failure message and destroy secret
v3: change to generic naming to use for TDX and SEV and use new mechanism
v4: review fixes
---
grub
passed in argument to recover_key() makes
this possible.
Signed-off-by: James Bottomley
---
v2: add conditional prompting to geli.c
v3: make getter specify prompt requirement
---
grub-core/disk/cryptodisk.c| 2 +-
grub-core/disk/geli.c | 12 +++-
grub-core/disk
s you a list you can trim)?
>
> On Tue, Nov 09, 2021 at 08:53:53AM -0500, James Bottomley wrote:
> > From: James Bottomley
> >
> > v3: make password getter specify prompt requirement. Update for
> > TDX:
> > Make name more generic and expand size of secret ar
On Mon, 2022-01-24 at 23:42 -0600, Glenn Washburn wrote:
> On Mon, 24 Jan 2022 06:12:17 -0800
> Hernan Gatta wrote:
[...]
> > +}
> > +
> >if (state[0].set) /* uuid */
> > {
> >int found_uuid;
> > @@ -1385,7 +1404,7 @@ GRUB_MOD_INIT (cryptodisk)
> > {
> >grub_disk_dev_regi
From: James Bottomley
v4: Update to new password passing API and fold in review comments
original patch 1 (which contained a password passing API) is
removed and patch 2 is updated and patch 3 largely unchanged.
v3: make password getter specify prompt requirement. Update for TDX
al machine. OVMF
provides the secret area and passes it into the EFI Configuration
Tables. The grub EFI layer pulls the secret out and primes the
secrets API with it. The upshot of all of this is that a SEV
protected VM can do an encrypted boot with a protected boot secret.
Signed-off-by: James
x27;t need large numbers of
iterations, use a base64 encoding of 33 bytes of random data.
Signed-off-by: James Bottomley
---
v2: use callback to print failure message and destroy secret
v3: change to generic naming to use for TDX and SEV and use new mechanism
v4: review fixes
---
grub
On Mon, 2022-02-07 at 17:00 +, Dr. David Alan Gilbert wrote:
> * James Bottomley (j...@linux.ibm.com) wrote:
[...]
> > +static grub_err_t
> > +grub_efi_secret_put (const char *arg __attribute__((unused)), int
> > have_it,
> > +grub_uint8_t
On Mon, 2022-02-14 at 16:18 -0600, Glenn Washburn wrote:
> On Mon, 7 Feb 2022 10:29:43 -0500
> James Bottomley wrote:
>
> > Make use of the new OS provided secrets API so that if the new '-s'
> > option is passed in we try to extract the secret from the API
&
On Wed, 2022-03-30 at 09:39 +0200, Ard Biesheuvel wrote:
> On Wed, 30 Mar 2022 at 09:27, Matthew Garrett
> wrote:
> > On Wed, Mar 30, 2022 at 09:23:17AM +0200, Ard Biesheuvel wrote:
> > > On Wed, 30 Mar 2022 at 09:19, Matthew Garrett <
> > > mj...@srcf.ucam.org> wrote:
> > > > From a conceptual pe
On Tue, 2022-05-10 at 12:28 +0200, Łukasz Piątkowski wrote:
> Hi everyone - I'm new here!
>
> Sorry for going with my problem directly to the grub-devel maling
> list, but I'm pretty sure my problem is GRUB related. Still, I've
> spent some hours trying to find a solution on the Internet and I
> f
On Fri, 2024-04-19 at 16:30 +0800, Gary Lin wrote:
> TPMKey ::= SEQUENCE {
> type OBJECT IDENTIFIER
> emptyAuth [0] EXPLICIT BOOLEAN OPTIONAL
> policy [1] EXPLICIT SEQUENCE OF TPMPolicy OPTIONAL
> secret [2] EXPLICIT OCTET STRING OPTIONAL
> authPolicy
On Wed, 2023-02-22 at 15:00 +0800, Gary Lin via Grub-devel wrote:
> +GRUB_MOD_INIT (tpm2)
> +{
> + grub_tpm2_protector_init_cmd =
> + grub_register_extcmd ("tpm2_key_protector_init",
> + grub_tpm2_protector_init_cmd_handler, 0,
> + N_("[-m mode] "
On Mon, 2023-03-06 at 14:51 +0800, Gary Lin wrote:
> On Wed, Feb 22, 2023 at 07:41:38AM -0500, James Bottomley wrote:
> > On Wed, 2023-02-22 at 15:00 +0800, Gary Lin via Grub-devel wrote:
> > > +GRUB_MOD_INIT (tpm2)
> > > +{
> > > + grub_tpm2_protector_init_c
On Tue, 2024-01-16 at 17:20 +0800, Gary Lin via Grub-devel wrote:
[...]
> (*1) https://www.hansenpartnership.com/draft-bottomley-tpm2-keys.html
> (*2) https://github.com/okirch/pcr-oracle
Just a curiosity question, but have you tested the interoperability of
pcr-oracle keys? It looks like you got
On Mon, 2024-02-05 at 15:27 +0800, Gary Lin via Grub-devel wrote:
> On Wed, Jan 17, 2024 at 04:13:17PM +0800, Gary Lin wrote:
> > On Tue, Jan 16, 2024 at 10:39:45AM -0500, James Bottomley wrote:
> > > On Tue, 2024-01-16 at 17:20 +0800, Gary Lin via Grub-devel wrote:
>
On Tue, 2024-02-06 at 14:12 +0800, Gary Lin via Grub-devel wrote:
> On Mon, Feb 05, 2024 at 08:48:53AM +0000, James Bottomley wrote:
[...]
> > It was for two reasons: 1) so we all derive the same parent for
> > interoperability and 2) because some TPMs take forever to derive an
>
On Wed, 2024-11-06 at 18:48 -0500, Stefan Berger wrote:
>
>
> On 11/4/24 2:32 AM, Gary Lin via Grub-devel wrote:
> > Update the user manual to address TPM2 key protector including the
> > two
> > related commands, tpm2_key_protector_init and
> > tpm2_key_protector_clear,
> > and the user-space ut
47 matches
Mail list logo
