All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Dov Murik <dovmurik@linux.ibm.com>
Cc: linux-efi@vger.kernel.org, Borislav Petkov <bp@suse.de>,
	Ashish Kalra <ashish.kalra@amd.com>,
	Brijesh Singh <brijesh.singh@amd.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	James Morris <jmorris@namei.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	Andi Kleen <ak@linux.intel.com>, Andrew Scull <ascull@google.com>,
	Dave Hansen <dave.hansen@intel.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	James Bottomley <jejb@linux.ibm.com>,
	Tobin Feldman-Fitzthum <tobin@linux.ibm.com>,
	Jim Cadden <jcadden@ibm.com>,
	Daniele Buono <dbuono@linux.vnet.ibm.com>,
	linux-coco@lists.linux.dev,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 3/4] virt: Add efi_secret module to expose confidential computing secrets
Date: Thu, 18 Nov 2021 13:43:10 +0100	[thread overview]
Message-ID: <YZZKXowcApyC/CEF@kroah.com> (raw)
In-Reply-To: <20211118113359.642571-4-dovmurik@linux.ibm.com>

On Thu, Nov 18, 2021 at 11:33:58AM +0000, Dov Murik wrote:
> The new efi_secret module exposes the confidential computing (coco)
> EFI secret area via securityfs interface.
> 
> When the module is loaded (and securityfs is mounted, typically under
> /sys/kernel/security), a "coco/efi_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 "coco/efi_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@linux.ibm.com>
> ---
>  .../ABI/testing/securityfs-coco-efi_secret    |  50 +++
>  drivers/virt/Kconfig                          |   3 +
>  drivers/virt/Makefile                         |   1 +
>  drivers/virt/coco/efi_secret/Kconfig          |  11 +
>  drivers/virt/coco/efi_secret/Makefile         |   2 +
>  drivers/virt/coco/efi_secret/efi_secret.c     | 341 ++++++++++++++++++
>  6 files changed, 408 insertions(+)
>  create mode 100644 Documentation/ABI/testing/securityfs-coco-efi_secret
>  create mode 100644 drivers/virt/coco/efi_secret/Kconfig
>  create mode 100644 drivers/virt/coco/efi_secret/Makefile
>  create mode 100644 drivers/virt/coco/efi_secret/efi_secret.c
> 
> diff --git a/Documentation/ABI/testing/securityfs-coco-efi_secret b/Documentation/ABI/testing/securityfs-coco-efi_secret
> new file mode 100644
> index 000000000000..ae56976db1bc
> --- /dev/null
> +++ b/Documentation/ABI/testing/securityfs-coco-efi_secret
> @@ -0,0 +1,50 @@
> +What:		security/coco/efi_secret
> +Date:		October 2021
> +Contact:	Dov Murik <dovmurik@linux.ibm.com>
> +Description:
> +		Exposes confidential computing (coco) EFI secrets to
> +		userspace via securityfs.
> +
> +		EFI can declare memory area used by confidential computing
> +		platforms (such as AMD SEV and SEV-ES) for secret injection by
> +		the Guest Owner during VM's launch.  The secrets are encrypted
> +		by the Guest Owner and decrypted inside the trusted enclave,
> +		and therefore are not readable by the untrusted host.
> +
> +		The efi_secret module exposes the secrets to userspace.  Each
> +		secret appears as a file under <securityfs>/coco/efi_secret,
> +		where the filename is the GUID of the entry in the secrets
> +		table.
> +
> +		Two operations are supported for the files: read and unlink.
> +		Reading the file returns the content of secret entry.
> +		Unlinking the file overwrites the secret data with zeroes and
> +		removes the entry from the filesystem.  A secret cannot be read
> +		after it has been unlinked.
> +
> +		For example, listing the available secrets::
> +
> +		  # modprobe efi_secret
> +		  # ls -l /sys/kernel/security/coco/efi_secret
> +		  -r--r----- 1 root root 0 Jun 28 11:54 736870e5-84f0-4973-92ec-06879ce3da0b
> +		  -r--r----- 1 root root 0 Jun 28 11:54 83c83f7f-1356-4975-8b7e-d3a0b54312c6
> +		  -r--r----- 1 root root 0 Jun 28 11:54 9553f55d-3da2-43ee-ab5d-ff17f78864d2
> +		  -r--r----- 1 root root 0 Jun 28 11:54 e6f5a162-d67f-4750-a67c-5d065f2a9910
> +
> +		Reading the secret data by reading a file::
> +
> +		  # cat /sys/kernel/security/coco/efi_secret/e6f5a162-d67f-4750-a67c-5d065f2a9910
> +		  the-content-of-the-secret-data
> +
> +		Wiping a secret by unlinking a file::
> +
> +		  # rm /sys/kernel/security/coco/efi_secret/e6f5a162-d67f-4750-a67c-5d065f2a9910
> +		  # ls -l /sys/kernel/security/coco/efi_secret
> +		  -r--r----- 1 root root 0 Jun 28 11:54 736870e5-84f0-4973-92ec-06879ce3da0b
> +		  -r--r----- 1 root root 0 Jun 28 11:54 83c83f7f-1356-4975-8b7e-d3a0b54312c6
> +		  -r--r----- 1 root root 0 Jun 28 11:54 9553f55d-3da2-43ee-ab5d-ff17f78864d2
> +
> +		Note: The binary format of the secrets table injected by the
> +		Guest Owner is described in
> +		drivers/virt/coco/efi_secret/efi_secret.c under "Structure of
> +		the EFI secret area".
> diff --git a/drivers/virt/Kconfig b/drivers/virt/Kconfig
> index 8061e8ef449f..fe7a6579b974 100644
> --- a/drivers/virt/Kconfig
> +++ b/drivers/virt/Kconfig
> @@ -36,4 +36,7 @@ source "drivers/virt/vboxguest/Kconfig"
>  source "drivers/virt/nitro_enclaves/Kconfig"
>  
>  source "drivers/virt/acrn/Kconfig"
> +
> +source "drivers/virt/coco/efi_secret/Kconfig"
> +
>  endif
> diff --git a/drivers/virt/Makefile b/drivers/virt/Makefile
> index 3e272ea60cd9..efdb015783f9 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-$(CONFIG_EFI_SECRET)	+= coco/efi_secret/
> diff --git a/drivers/virt/coco/efi_secret/Kconfig b/drivers/virt/coco/efi_secret/Kconfig
> new file mode 100644
> index 000000000000..a39a5a90a1e5
> --- /dev/null
> +++ b/drivers/virt/coco/efi_secret/Kconfig
> @@ -0,0 +1,11 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +config EFI_SECRET
> +	tristate "EFI secret area securityfs support"
> +	depends on EFI
> +	select EFI_COCO_SECRET
> +	select SECURITYFS
> +	help
> +	  This is a driver for accessing the EFI secret area via securityfs.
> +
> +	  To compile this driver as a module, choose M here.
> +	  The module will be called efi_secret.


Shouldn't this module auto-load only if the efi secret area is present?

What is going to cause the module to be loaded by a distro if it does
not have some sort of way to tell userspace what resources it belongs
to?  Can you trigger off of a DMI or EFI attribute somehow for this?

Otherwise you are going to force distros to modify their init scripts
for this functionality, how is that going to happen?

thanks,

greg k-h

  reply	other threads:[~2021-11-18 12:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-18 11:33 [PATCH v5 0/4] Allow guest access to EFI confidential computing secret area Dov Murik
2021-11-18 11:33 ` [PATCH v5 1/4] efi: Save location of EFI confidential computing area Dov Murik
2021-11-18 11:33 ` [PATCH v5 2/4] efi/libstub: Reserve confidential computing secret area Dov Murik
2021-11-18 11:33 ` [PATCH v5 3/4] virt: Add efi_secret module to expose confidential computing secrets Dov Murik
2021-11-18 12:43   ` Greg KH [this message]
2021-11-18 16:13   ` kernel test robot
2021-11-19  3:51   ` kernel test robot
2021-11-18 11:33 ` [PATCH v5 4/4] docs: security: Add coco/efi_secret documentation Dov Murik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YZZKXowcApyC/CEF@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=ak@linux.intel.com \
    --cc=ardb@kernel.org \
    --cc=ascull@google.com \
    --cc=ashish.kalra@amd.com \
    --cc=bp@suse.de \
    --cc=brijesh.singh@amd.com \
    --cc=dave.hansen@intel.com \
    --cc=dbuono@linux.vnet.ibm.com \
    --cc=dgilbert@redhat.com \
    --cc=dovmurik@linux.ibm.com \
    --cc=jcadden@ibm.com \
    --cc=jejb@linux.ibm.com \
    --cc=jmorris@namei.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=serge@hallyn.com \
    --cc=thomas.lendacky@amd.com \
    --cc=tobin@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.