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
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 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 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-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, 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 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 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 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 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 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
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
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
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
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
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
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
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
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
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
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 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 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 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 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-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 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 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 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
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
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
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
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
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
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
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
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
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
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
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 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 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
>
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
---
grub-core/Makefile.core.def| 8 +++
grub-core/disk/efi/sevsecret.c | 118 +
include/grub/efi/api.h | 15 +
3 files changed, 141 inser
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
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
47 matches
Mail list logo
