mbox series

[0/3] Allow access to confidential computing secret area in SEV guests

Message ID 20210809190157.279332-1-dovmurik@linux.ibm.com (mailing list archive)
Headers show
Series Allow access to confidential computing secret area in SEV guests | expand

Message

Dov Murik Aug. 9, 2021, 7:01 p.m. UTC
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
total 0
drwxr-xr-x 2 root root 0 Jun 28 11:54 .
drwxr-xr-x 3 root root 0 Jun 28 11:54 ..
-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

# xxd /sys/kernel/security/coco/sev_secret/e6f5a162-d67f-4750-a67c-5d065f2a9910
00000000: 7468 6573 652d 6172 652d 7468 652d 6b61  these-are-the-ka
00000010: 7461 2d73 6563 7265 7473 0001 0203 0405  ta-secrets......
00000020: 0607                                     ..

# rm /sys/kernel/security/coco/sev_secret/e6f5a162-d67f-4750-a67c-5d065f2a9910

# ls -la /sys/kernel/security/coco/sev_secret
total 0
drwxr-xr-x 2 root root 0 Jun 28 11:55 .
drwxr-xr-x 3 root root 0 Jun 28 11:54 ..
-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


Previously sent as an RFC series [2].

[1] https://github.com/tianocore/edk2/commit/01726b6d23d4
[2] https://lore.kernel.org/linux-coco/20210628183431.953934-1-dovmurik@linux.ibm.com/


Dov Murik (3):
  efi/libstub: Copy confidential computing secret area
  efi: Reserve confidential computing secret area
  virt: Add sev_secret module to expose confidential computing secrets

 arch/x86/platform/efi/efi.c               |   1 +
 drivers/firmware/efi/Makefile             |   2 +-
 drivers/firmware/efi/coco.c               |  41 +++
 drivers/firmware/efi/efi.c                |   3 +
 drivers/firmware/efi/libstub/Makefile     |   2 +-
 drivers/firmware/efi/libstub/coco.c       |  68 +++++
 drivers/firmware/efi/libstub/efi-stub.c   |   2 +
 drivers/firmware/efi/libstub/efistub.h    |   2 +
 drivers/firmware/efi/libstub/x86-stub.c   |   2 +
 drivers/virt/Kconfig                      |   3 +
 drivers/virt/Makefile                     |   1 +
 drivers/virt/coco/sev_secret/Kconfig      |  11 +
 drivers/virt/coco/sev_secret/Makefile     |   2 +
 drivers/virt/coco/sev_secret/sev_secret.c | 313 ++++++++++++++++++++++
 include/linux/efi.h                       |   9 +
 15 files changed, 460 insertions(+), 2 deletions(-)
 create mode 100644 drivers/firmware/efi/coco.c
 create mode 100644 drivers/firmware/efi/libstub/coco.c
 create mode 100644 drivers/virt/coco/sev_secret/Kconfig
 create mode 100644 drivers/virt/coco/sev_secret/Makefile
 create mode 100644 drivers/virt/coco/sev_secret/sev_secret.c


base-commit: 36a21d51725af2ce0700c6ebcb6b9594aac658a6

Comments

Greg KH Sept. 2, 2021, 12:57 p.m. UTC | #1
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
James Bottomley Sept. 2, 2021, 2:35 p.m. UTC | #2
On Thu, 2021-09-02 at 14:57 +0200, Greg KH wrote:
[...]
> Wait, why are you using securityfs for this?
> 
> securityfs is for LSMs to use. 

No it isn't ... at least not exclusively; we use it for non LSM
security purposes as well, like for the TPM BIOS log and for IMA.  What
makes you think we should start restricting securityfs to LSMs only? 
That's not been the policy up to now.
 
>  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.

This is a security purpose (injected key retrieval), so securityfs
seems to be the best choice.  It's certainly possible to create a new
filesystem, but I really think things with a security purpose should
use securityfs so people know where to look for them.

James


> 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
Greg KH Sept. 2, 2021, 3:05 p.m. UTC | #3
On Thu, Sep 02, 2021 at 07:35:10AM -0700, James Bottomley wrote:
> On Thu, 2021-09-02 at 14:57 +0200, Greg KH wrote:
> [...]
> > Wait, why are you using securityfs for this?
> > 
> > securityfs is for LSMs to use. 
> 
> No it isn't ... at least not exclusively; we use it for non LSM
> security purposes as well, like for the TPM BIOS log and for IMA.  What
> makes you think we should start restricting securityfs to LSMs only? 
> That's not been the policy up to now.

Well that was the original intent of the filesystem when it was created,
but I guess it's really up to the LSM maintainers now what they want it
for.

> >  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.
> 
> This is a security purpose (injected key retrieval), so securityfs
> seems to be the best choice.  It's certainly possible to create a new
> filesystem, but I really think things with a security purpose should
> use securityfs so people know where to look for them.

knowing where to look should not be an issue, as that should be
documented in Documentation/ABI/ anyway, right?

It's just the overlap / overreach of using an existing filesystem for
things that don't seem to be LSM-related that feels odd to me.

Why not just make a cocofs if those people want a filesystem interface?
It's 200 lines or so these days, if not less, and that way you only
mount what you actually need for the system.

Why force this into securityfs if it doesn't have to be?

thanks,

greg k-h
James Bottomley Sept. 2, 2021, 3:19 p.m. UTC | #4
On Thu, 2021-09-02 at 17:05 +0200, Greg KH wrote:
> On Thu, Sep 02, 2021 at 07:35:10AM -0700, James Bottomley wrote:
> > On Thu, 2021-09-02 at 14:57 +0200, Greg KH wrote:
> > [...]
> > > Wait, why are you using securityfs for this?
> > > 
> > > securityfs is for LSMs to use. 
> > 
> > No it isn't ... at least not exclusively; we use it for non LSM
> > security purposes as well, like for the TPM BIOS log and for
> > IMA.  What makes you think we should start restricting securityfs
> > to LSMs only?  That's not been the policy up to now.
> 
> Well that was the original intent of the filesystem when it was
> created, but I guess it's really up to the LSM maintainers now what
> they want it for.
> 
> > >  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.
> > 
> > This is a security purpose (injected key retrieval), so securityfs
> > seems to be the best choice.  It's certainly possible to create a
> > new filesystem, but I really think things with a security purpose
> > should use securityfs so people know where to look for them.
> 
> knowing where to look should not be an issue, as that should be
> documented in Documentation/ABI/ anyway, right?
> 
> It's just the overlap / overreach of using an existing filesystem for
> things that don't seem to be LSM-related that feels odd to me.
> 
> Why not just make a cocofs if those people want a filesystem
> interface?
> It's 200 lines or so these days, if not less, and that way you only
> mount what you actually need for the system.

Secrets transfer is actually broader than confidential computing,
although confidential computing is a first proposed use, so I think
cocofs would be too narrow.

> Why force this into securityfs if it doesn't have to be?

It's not being forced.  Secrets transfer is a security function in the
same way the bios log is.

James
Greg KH Sept. 2, 2021, 4:09 p.m. UTC | #5
On Thu, Sep 02, 2021 at 08:19:51AM -0700, James Bottomley wrote:
> On Thu, 2021-09-02 at 17:05 +0200, Greg KH wrote:
> > On Thu, Sep 02, 2021 at 07:35:10AM -0700, James Bottomley wrote:
> > > On Thu, 2021-09-02 at 14:57 +0200, Greg KH wrote:
> > > [...]
> > > > Wait, why are you using securityfs for this?
> > > > 
> > > > securityfs is for LSMs to use. 
> > > 
> > > No it isn't ... at least not exclusively; we use it for non LSM
> > > security purposes as well, like for the TPM BIOS log and for
> > > IMA.  What makes you think we should start restricting securityfs
> > > to LSMs only?  That's not been the policy up to now.
> > 
> > Well that was the original intent of the filesystem when it was
> > created, but I guess it's really up to the LSM maintainers now what
> > they want it for.
> > 
> > > >  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.
> > > 
> > > This is a security purpose (injected key retrieval), so securityfs
> > > seems to be the best choice.  It's certainly possible to create a
> > > new filesystem, but I really think things with a security purpose
> > > should use securityfs so people know where to look for them.
> > 
> > knowing where to look should not be an issue, as that should be
> > documented in Documentation/ABI/ anyway, right?
> > 
> > It's just the overlap / overreach of using an existing filesystem for
> > things that don't seem to be LSM-related that feels odd to me.
> > 
> > Why not just make a cocofs if those people want a filesystem
> > interface?
> > It's 200 lines or so these days, if not less, and that way you only
> > mount what you actually need for the system.
> 
> Secrets transfer is actually broader than confidential computing,
> although confidential computing is a first proposed use, so I think
> cocofs would be too narrow.
> 
> > Why force this into securityfs if it doesn't have to be?
> 
> It's not being forced.  Secrets transfer is a security function in the
> same way the bios log is.

Is the bios log in securityfs today?

Anyway, it's up to the securityfs maintainer (i.e. not me), but
personally, I think this should be a separate filesystem as that would
probably make things easier in the long run...

good luck!

greg k-h
James Bottomley Sept. 2, 2021, 4:19 p.m. UTC | #6
On Thu, 2021-09-02 at 18:09 +0200, Greg KH wrote:
> On Thu, Sep 02, 2021 at 08:19:51AM -0700, James Bottomley wrote:
> > On Thu, 2021-09-02 at 17:05 +0200, Greg KH wrote:
> > > On Thu, Sep 02, 2021 at 07:35:10AM -0700, James Bottomley wrote:
> > > > On Thu, 2021-09-02 at 14:57 +0200, Greg KH wrote:
> > > > [...]
> > > > > Wait, why are you using securityfs for this?
> > > > > 
> > > > > securityfs is for LSMs to use. 
> > > > 
> > > > No it isn't ... at least not exclusively; we use it for non LSM
> > > > security purposes as well, like for the TPM BIOS log and for
> > > > IMA.  What makes you think we should start restricting
> > > > securityfs to LSMs only?  That's not been the policy up to now.
> > > 
> > > Well that was the original intent of the filesystem when it was
> > > created, but I guess it's really up to the LSM maintainers now
> > > what they want it for.
> > > 
> > > > >  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.
> > > > 
> > > > This is a security purpose (injected key retrieval), so
> > > > securityfs seems to be the best choice.  It's certainly
> > > > possible to create a new filesystem, but I really think things
> > > > with a security purpose should use securityfs so people know
> > > > where to look for them.
> > > 
> > > knowing where to look should not be an issue, as that should be
> > > documented in Documentation/ABI/ anyway, right?
> > > 
> > > It's just the overlap / overreach of using an existing filesystem
> > > for things that don't seem to be LSM-related that feels odd to
> > > me.
> > > 
> > > Why not just make a cocofs if those people want a filesystem
> > > interface?
> > > It's 200 lines or so these days, if not less, and that way you
> > > only mount what you actually need for the system.
> > 
> > Secrets transfer is actually broader than confidential computing,
> > although confidential computing is a first proposed use, so I think
> > cocofs would be too narrow.
> > 
> > > Why force this into securityfs if it doesn't have to be?
> > 
> > It's not being forced.  Secrets transfer is a security function in
> > the same way the bios log is.
> 
> Is the bios log in securityfs today?

Yes. It's under /sys/kernel/security/tpm0/  All the ima policy control
and its log is under /sys/kernel/security/ima/  that's why I think
declaring securityfs as being for anything security related is already
our de facto (if not de jure) policy.

> Anyway, it's up to the securityfs maintainer (i.e. not me), but
> personally, I think this should be a separate filesystem as that
> would probably make things easier in the long run...

I know Al likes this business of loads of separate filesystems, but
personally I'm not in favour.  For every one you do, you not only have
to document it all, you also have to find a preferred mount point that
the distributions can agree on and also have them agree to enable the
mount for, which often takes months of negotiation.  Having fewer
filesystems grouped by common purpose which have agreed mount points
that distros actually mount seems a far easier approach to enablement.

James
Greg KH Sept. 2, 2021, 4:31 p.m. UTC | #7
On Thu, Sep 02, 2021 at 09:19:13AM -0700, James Bottomley wrote:
> On Thu, 2021-09-02 at 18:09 +0200, Greg KH wrote:
> > On Thu, Sep 02, 2021 at 08:19:51AM -0700, James Bottomley wrote:
> > > On Thu, 2021-09-02 at 17:05 +0200, Greg KH wrote:
> > > > On Thu, Sep 02, 2021 at 07:35:10AM -0700, James Bottomley wrote:
> > > > > On Thu, 2021-09-02 at 14:57 +0200, Greg KH wrote:
> > > > > [...]
> > > > > > Wait, why are you using securityfs for this?
> > > > > > 
> > > > > > securityfs is for LSMs to use. 
> > > > > 
> > > > > No it isn't ... at least not exclusively; we use it for non LSM
> > > > > security purposes as well, like for the TPM BIOS log and for
> > > > > IMA.  What makes you think we should start restricting
> > > > > securityfs to LSMs only?  That's not been the policy up to now.
> > > > 
> > > > Well that was the original intent of the filesystem when it was
> > > > created, but I guess it's really up to the LSM maintainers now
> > > > what they want it for.
> > > > 
> > > > > >  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.
> > > > > 
> > > > > This is a security purpose (injected key retrieval), so
> > > > > securityfs seems to be the best choice.  It's certainly
> > > > > possible to create a new filesystem, but I really think things
> > > > > with a security purpose should use securityfs so people know
> > > > > where to look for them.
> > > > 
> > > > knowing where to look should not be an issue, as that should be
> > > > documented in Documentation/ABI/ anyway, right?
> > > > 
> > > > It's just the overlap / overreach of using an existing filesystem
> > > > for things that don't seem to be LSM-related that feels odd to
> > > > me.
> > > > 
> > > > Why not just make a cocofs if those people want a filesystem
> > > > interface?
> > > > It's 200 lines or so these days, if not less, and that way you
> > > > only mount what you actually need for the system.
> > > 
> > > Secrets transfer is actually broader than confidential computing,
> > > although confidential computing is a first proposed use, so I think
> > > cocofs would be too narrow.
> > > 
> > > > Why force this into securityfs if it doesn't have to be?
> > > 
> > > It's not being forced.  Secrets transfer is a security function in
> > > the same way the bios log is.
> > 
> > Is the bios log in securityfs today?
> 
> Yes. It's under /sys/kernel/security/tpm0/  All the ima policy control
> and its log is under /sys/kernel/security/ima/  that's why I think
> declaring securityfs as being for anything security related is already
> our de facto (if not de jure) policy.
> 
> > Anyway, it's up to the securityfs maintainer (i.e. not me), but
> > personally, I think this should be a separate filesystem as that
> > would probably make things easier in the long run...
> 
> I know Al likes this business of loads of separate filesystems, but
> personally I'm not in favour.  For every one you do, you not only have
> to document it all,

Wait, why would you not have to document your new files no matter what?
That should not be an issue either way.

> you also have to find a preferred mount point that
> the distributions can agree on and also have them agree to enable the
> mount for,

You create that yourself, just like tracefs does, and set the standard
right away, not an issue.

> which often takes months of negotiation.

Enabling it does take time, which is good because if they do not think
it should be present because they do not want to use it, then it will
not be, which means either they do not need your new feature, or you
have not made it useful enough.

So again, not an issue.
And you can even mount it yourself from the kernel if you insist on it
always being present.

> Having fewer
> filesystems grouped by common purpose which have agreed mount points
> that distros actually mount seems a far easier approach to enablement.

The issue is that random things gets added to those filesystems,
exposing stuff that perhaps some systems do NOT want exposed to
userspace.  Making it explicit as to what they have to mount to get
access to that is a good thing because you have less of an "attack
surface" and all of that.

So again, this should not be an issue.  If coco stuff is so important
that people need it, then having them have to add it to their init
scripts just to mount the filesystem is not an issue as there are other
userspace components of all of this mess that they had to install
anyway.  Just make it part of the userspace tools that are going to be
accessing these files because you have to get those onto the systems no
matter what.

greg k-h