linux-kernel - Re: [RFC PATCH v2 3/3] virt: Add sev_secret module to expose confidential computing secrets

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: <YNojYBIwk0xCHQ0v@zn.tnic>
Date:   Mon, 28 Jun 2021 21:30:40 +0200
From:   Borislav Petkov <bp@...e.de>
To:     Dov Murik <dovmurik@...ux.ibm.com>
Cc:     linux-efi@...r.kernel.org, Laszlo Ersek <lersek@...hat.com>,
        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: [RFC PATCH v2 3/3] virt: Add sev_secret module to expose
 confidential computing secrets

On Mon, Jun 28, 2021 at 06:34:31PM +0000, Dov Murik wrote:
> The new sev_secret module exposes the confidential computing secret area
> via securityfs interface.
> 
> When the module is loaded (and securityfs is mounted, typically under
> /sys/kernel/security), an "sev_secret" directory is created in
> securityfs.  In it, a file is created for each secret entry.  The name
> of each such file is the GUID of the secret entry, and its content is
> the secret data.
> 
> This allows applications running in a confidential computing setting to
> read secrets provided by the guest owner via a secure secret injection
> mechanism (such as AMD SEV's LAUNCH_SECRET command).
> 
> Removing (unlinking) files in the "sev_secret" directory will zero out
> the secret in memory, and remove the filesystem entry.  If the module
> is removed and loaded again, that secret will not appear in the
> filesystem.
> 
> Signed-off-by: Dov Murik <dovmurik@...ux.ibm.com>
> ---
>  drivers/virt/Kconfig                 |   2 +
>  drivers/virt/Makefile                |   1 +
>  drivers/virt/sev_secret/Kconfig      |  11 +
>  drivers/virt/sev_secret/Makefile     |   2 +
>  drivers/virt/sev_secret/sev_secret.c | 298 +++++++++++++++++++++++++++
>  5 files changed, 314 insertions(+)
>  create mode 100644 drivers/virt/sev_secret/Kconfig
>  create mode 100644 drivers/virt/sev_secret/Makefile
>  create mode 100644 drivers/virt/sev_secret/sev_secret.c

Same question here: maybe have 

drivers/virt/coco/

and put all coco guest stuff in there.

> diff --git a/drivers/virt/Kconfig b/drivers/virt/Kconfig
> index 8061e8ef449f..c222cc625891 100644
> --- a/drivers/virt/Kconfig
> +++ b/drivers/virt/Kconfig
> @@ -36,4 +36,6 @@ source "drivers/virt/vboxguest/Kconfig"
>  source "drivers/virt/nitro_enclaves/Kconfig"
>  
>  source "drivers/virt/acrn/Kconfig"
> +
> +source "drivers/virt/sev_secret/Kconfig"
>  endif
> diff --git a/drivers/virt/Makefile b/drivers/virt/Makefile
> index 3e272ea60cd9..0765e5418d1d 100644
> --- a/drivers/virt/Makefile
> +++ b/drivers/virt/Makefile
> @@ -8,3 +8,4 @@ obj-y				+= vboxguest/
>  
>  obj-$(CONFIG_NITRO_ENCLAVES)	+= nitro_enclaves/
>  obj-$(CONFIG_ACRN_HSM)		+= acrn/
> +obj-y				+= sev_secret/
> diff --git a/drivers/virt/sev_secret/Kconfig b/drivers/virt/sev_secret/Kconfig
> new file mode 100644
> index 000000000000..4505526b8ef1
> --- /dev/null
> +++ b/drivers/virt/sev_secret/Kconfig
> @@ -0,0 +1,11 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +config AMD_SEV_SECRET_SECURITYFS
> +	tristate "AMD SEV secret area securityfs support"
> +	depends on EFI

That probably needs to depend on CONFIG_AMD_MEM_ENCRYPT - otherwise
what's the point for it.

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg