linux-kernel - Re: [PATCH v8 0/4] Allow guest access to EFI confidential computing secret area

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YkNQNzNa02Sndu+q@zn.tnic>
Date:   Tue, 29 Mar 2022 20:30:15 +0200
From:   Borislav Petkov <bp@...e.de>
To:     Dov Murik <dovmurik@...ux.ibm.com>
Cc:     linux-efi@...r.kernel.org, Ashish Kalra <ashish.kalra@....com>,
        Brijesh Singh <brijesh.singh@....com>,
        Tom Lendacky <thomas.lendacky@....com>,
        Ard Biesheuvel <ardb@...nel.org>,
        James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Andrew Scull <ascull@...gle.com>,
        Dave Hansen <dave.hansen@...el.com>,
        "Dr. David Alan Gilbert" <dgilbert@...hat.com>,
        Gerd Hoffmann <kraxel@...hat.com>,
        Lenny Szubowicz <lszubowi@...hat.com>,
        Peter Gonda <pgonda@...gle.com>,
        Matthew Garrett <mjg59@...f.ucam.org>,
        James Bottomley <jejb@...ux.ibm.com>,
        Tobin Feldman-Fitzthum <tobin@...ux.ibm.com>,
        Jim Cadden <jcadden@....com>,
        Daniele Buono <dbuono@...ux.vnet.ibm.com>,
        linux-coco@...ts.linux.dev, linux-security-module@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 0/4] Allow guest access to EFI confidential computing
 secret area

Hi Dov,

On Tue, Mar 29, 2022 at 03:55:38PM +0300, Dov Murik wrote:
> Let's see if I understand this correctly:
> 
> You want the guest to know if the its own SEV VM policy allows
> debugging.  And that flag has to be trusted -- so passed from the Guest
> Owner in a secure channel (otherwise the host could set it to
> ALLOW_DEBUGGING even though the Guest Owner didn't approve that).

Yeah, and then dump all the guest memory and thus bypass the whole
memory encryption fun. So yeah, it should be encrypted and accessible
only to the guest and supplied by the guest owner.

> The SEV launch secrets area can also be read by grub [1], for example,
> to fetch a luks passphrase from there (instead of from keyboard).
> That's why its structure is generic.

Ok, fair enough.

> I think Guest Owner can add a 1-byte predefined secret to the SEV secret
> table, let's say an entry with GUID 2b91a212-b0e1-4816-b021-1e9991ddb6af
> and value "\x01" to indicate debugging is allowed.
> 
> With the efi_secrets module, a 1-byte file called
> /sys/kernel/security/secrets/coco/2b91a212-b0e1-4816-b021-1e9991ddb6af

I'd love it if that were more user-friendly:

/sys/kernel/security/secrets/coco/attributes

and there's:

debugging:1
...

and others.

> will appear with "\x01" in its content.
> 
> This can indicate to the guest that debugging was permitted by the Guest
> Owner.

But yeah, that should be the gist of the functionality.

> If you want this unified in the kernel, maybe we can look for this entry
> and set the relevant kernel variable.

So now that I think of it, it would be even nicer if the fact whether
guest debugging is allowed, were available to the guest *very early*
during boot. Because I think the most important cases where you'd want
to singlestep a SEV* guest with the qemu gdbstub is early guest kernel
boot code. So it would be cool if we'd have access to the debugging
setting that early.

Lemme have a look at your patches in detail to get an idea what's
happening there.

Thx.

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Ivo Totev, HRB 36809, AG Nürnberg