Message-ID: <YTDKUe8rXrr0Zika@kroah.com>
Date:   Thu, 2 Sep 2021 14:57:53 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Dov Murik <dovmurik@...ux.ibm.com>
Cc:     linux-efi@...r.kernel.org, Borislav Petkov <bp@...e.de>,
        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>,
        "Dr. David Alan Gilbert" <dgilbert@...hat.com>,
        James Bottomley <jejb@...ux.ibm.com>,
        Tobin Feldman-Fitzthum <tobin@...ux.ibm.com>,
        Jim Cadden <jcadden@....com>, linux-coco@...ts.linux.dev,
        linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] Allow access to confidential computing secret area
 in SEV guests

On Mon, Aug 09, 2021 at 07:01:54PM +0000, Dov Murik wrote:
> Confidential computing (coco) hardware such as AMD SEV (Secure Encrypted
> Virtualization) allows guest owners to inject secrets into the VMs
> memory without the host/hypervisor being able to read them.  In SEV,
> secret injection is performed early in the VM launch process, before the
> guest starts running.
> 
> OVMF already reserves designated area for secret injection (in its
> AmdSev package; see edk2 commit 01726b6d23d4 "OvmfPkg/AmdSev: Expose the
> Sev Secret area using a configuration table" [1]), but the secrets were
> not available in the guest kernel.
> 
> The patch series copies the secrets from the EFI-provided memory to
> kernel reserved memory, and optionally exposes them to userspace via
> securityfs using a new sev_secret kernel module.
> 
> The first patch in efi/libstub copies the secret area from the EFI
> memory to specially allocated memory; the second patch reserves that
> memory block; and the third patch introduces the new sev_secret module
> that exposes the content of the secret entries as securityfs files, and
> allows clearing out secrets with a file unlink interface.
> 
> As a usage example, consider a guest performing computations on
> encrypted files.  The Guest Owner provides the decryption key (= secret)
> using the secret injection mechanism.  The guest application reads the
> secret from the sev_secret filesystem and proceeds to decrypt the files
> into memory and then performs the needed computations on the content.
> 
> In this example, the host can't read the files from the disk image
> because they are encrypted.  Host can't read the decryption key because
> it is passed using the secret injection mechanism (= secure channel).
> Host can't read the decrypted content from memory because it's a
> confidential (memory-encrypted) guest.
> 
> This has been tested with AMD SEV guests, but the kernel side of
> handling the secret area has no SEV-specific dependencies, and therefore
> might be usable (perhaps with minor changes) for any confidential
> computing hardware that can publish the secret area via the standard EFI
> config table entry.
> 
> Here is a simple example for usage of the sev_secret module in a guest
> to which a secret are with 4 secrets was injected during launch:
> 
> # modprobe sev_secret
> # ls -la /sys/kernel/security/coco/sev_secret


Wait, why are you using securityfs for this?

securityfs is for LSMs to use.  If you want your own filesystem to play
around with stuff like this, great, write your own, it's only 200 lines
or less these days.  We used to do it all the time until people realized
they should just use sysfs for driver stuff.

But this isn't a driver, so sure, add your own virtual filesystem, mount
it somewhere and away you go, no messing around with securityfs, right?

thanks,

greg k-h

Powered by blists - more mailing lists