x86/sev: Carve out and export SNP guest messaging init routines

Currently, the sev-guest driver is the only user of SNP guest messaging. All
routines for initializing SNP guest messaging are impleme

x86/sev: Carve out and export SNP guest messaging init routines

Currently, the sev-guest driver is the only user of SNP guest messaging. All
routines for initializing SNP guest messaging are implemented within the
sev-guest driver and are not available during early boot.

In preparation for adding Secure TSC guest support, carve out APIs to allocate
and initialize the guest messaging descriptor context and make it part of
coco/sev/core.c. As there is no user of sev_guest_platform_data anymore,
remove the structure.

Signed-off-by: Nikunj A Dadhania <[email protected]>
Signed-off-by: Borislav Petkov (AMD) <[email protected]>
Reviewed-by: Tom Lendacky <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

virt: sev-guest: Use AES GCM crypto library

The sev-guest driver encryption code uses the crypto API for SNP guest
messaging with the AMD Security processor. In order to enable secure TSC,
SEV-SNP g

virt: sev-guest: Use AES GCM crypto library

The sev-guest driver encryption code uses the crypto API for SNP guest
messaging with the AMD Security processor. In order to enable secure TSC,
SEV-SNP guests need to send such a TSC_INFO message before the APs are
booted. Details from the TSC_INFO response will then be used to program the
VMSA before the APs are brought up.

However, the crypto API is not available this early in the boot process.

In preparation for moving the encryption code out of sev-guest to support
secure TSC and to ease review, switch to using the AES GCM library
implementation instead.

Drop __enc_payload() and dec_payload() helpers as both are small and can be
moved to the respective callers.

Signed-off-by: Nikunj A Dadhania <[email protected]>
Signed-off-by: Borislav Petkov (AMD) <[email protected]>
Reviewed-by: Tom Lendacky <[email protected]>
Acked-by: Borislav Petkov (AMD) <[email protected]>
Tested-by: Peter Gonda <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

virt: sevguest: Add TSM_REPORTS support for SNP_GET_EXT_REPORT

The sevguest driver was a first mover in the confidential computing
space. As a first mover that afforded some leeway to build the driv

virt: sevguest: Add TSM_REPORTS support for SNP_GET_EXT_REPORT

The sevguest driver was a first mover in the confidential computing
space. As a first mover that afforded some leeway to build the driver
without concern for common infrastructure.

Now that sevguest is no longer a singleton [1] the common operation of
building and transmitting attestation report blobs can / should be made
common. In this model the so called "TSM-provider" implementations can
share a common envelope ABI even if the contents of that envelope remain
vendor-specific. When / if the industry agrees on an attestation record
format, that definition can also fit in the same ABI. In the meantime
the kernel's maintenance burden is reduced and collaboration on the
commons is increased.

Convert sevguest to use CONFIG_TSM_REPORTS to retrieve the data that
the SNP_GET_EXT_REPORT ioctl produces. An example flow follows for
retrieving the report blob via the TSM interface utility,
assuming no nonce and VMPL==2:

report=/sys/kernel/config/tsm/report/report0
mkdir $report
echo 2 > $report/privlevel
dd if=/dev/urandom bs=64 count=1 > $report/inblob
hexdump -C $report/outblob # SNP report
hexdump -C $report/auxblob # cert_table
rmdir $report

Given that the platform implementation is free to return empty
certificate data if none is available it lets configfs-tsm be simplified
as it only needs to worry about wrapping SNP_GET_EXT_REPORT, and leave
SNP_GET_REPORT alone.

The old ioctls can be lazily deprecated, the main motivation of this
effort is to stop the proliferation of new ioctls, and to increase
cross-vendor collaboration.

Link: http://lore.kernel.org/r/[email protected] [1]
Cc: Borislav Petkov <[email protected]>
Cc: Tom Lendacky <[email protected]>
Cc: Dionna Glaze <[email protected]>
Cc: Jeremi Piotrowski <[email protected]>
Tested-by: Kuppuswamy Sathyanarayanan <[email protected]>
Tested-by: Alexey Kardashevskiy <[email protected]>
Reviewed-by: Tom Lendacky <[email protected]>
Signed-off-by: Dan Williams <[email protected]>

show more ...

virt: sevguest: Add CONFIG_CRYPTO dependency

This driver fails to link when CRYPTO is disabled, or in a loadable
module:

WARNING: unmet direct dependencies detected for CRYPTO_GCM
WARNING: unme

virt: sevguest: Add CONFIG_CRYPTO dependency

This driver fails to link when CRYPTO is disabled, or in a loadable
module:

WARNING: unmet direct dependencies detected for CRYPTO_GCM
WARNING: unmet direct dependencies detected for CRYPTO_AEAD2
Depends on [m]: CRYPTO [=m]
Selected by [y]:
- SEV_GUEST [=y] && VIRT_DRIVERS [=y] && AMD_MEM_ENCRYPT [=y]

x86_64-linux-ld: crypto/aead.o: in function `crypto_register_aeads':

Fixes: fce96cf04430 ("virt: Add SEV-SNP guest driver")
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Borislav Petkov (AMD) <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

virt: sevguest: Rename the sevguest dir and files to sev-guest

Rename the drivers/virt/coco/sevguest directory and files to sev-guest
so as to match the driver name.

[ bp: Rename Documentation/vi

virt: sevguest: Rename the sevguest dir and files to sev-guest

Rename the drivers/virt/coco/sevguest directory and files to sev-guest
so as to match the driver name.

[ bp: Rename Documentation/virt/coco/sevguest.rst too, as reported by sfr:
https://lore.kernel.org/r/[email protected] ]

Signed-off-by: Tom Lendacky <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Link: https://lore.kernel.org/r/2f5c9cb16e3a67599c8e3170f6c72c8712c47d53.1650464054.git.thomas.lendacky@amd.com

show more ...