mbox series

[00/10] Add dynamic boost control support

Message ID 20230420163140.14940-1-mario.limonciello@amd.com
Headers show
Series Add dynamic boost control support | expand

Message

Mario Limonciello April 20, 2023, 4:31 p.m. UTC 
Dynamic boost control is a feature of some SoCs that allows
an authenticated entity to send commands to the security processor
to control certain SOC characteristics with the intention to improve
performance.

This is implemented via a mechanism that a userspace application would
authenticate using a nonce and key exchange over an IOCTL interface.

After authentication is complete an application can exchange signed
messages with the security processor and both ends can validate the
data transmitted.

This series includes a test suite that can be run on real hardware
to ensure that the communication works as expected.  This can also be
used for an application to model the communication path.

Two sysfs files are introduced for reading the PSP bootloader version
as well as TEE version which can be useful data points for debugging
communication problems.

Mario Limonciello (10):
  crypto: ccp: Rename macro for security attributes
  crypto: ccp: Add support for displaying PSP firmware versions
  crypto: ccp: Add bootloader and TEE version offsets
  crypto: ccp: move setting PSP master to earlier in the init
  crypto: ccp: Add support for fetching a nonce for dynamic boost
    control
  crypto: ccp: Add support for setting user ID for dynamic boost control
  crypto: ccp: Add support for getting and setting DBC parameters
  crypto: ccp: Add a sample script for Dynamic Boost Control
  crypto: ccp: Add unit tests for dynamic boost control
  crypto: ccp: Add Mario to MAINTAINERS

 Documentation/ABI/testing/sysfs-driver-ccp |  18 ++
 MAINTAINERS                                |  11 +
 drivers/crypto/ccp/Makefile                |   3 +-
 drivers/crypto/ccp/dbc.c                   | 250 +++++++++++++++++++
 drivers/crypto/ccp/dbc.h                   |  56 +++++
 drivers/crypto/ccp/psp-dev.c               |  16 +-
 drivers/crypto/ccp/psp-dev.h               |   1 +
 drivers/crypto/ccp/sp-dev.h                |   7 +
 drivers/crypto/ccp/sp-pci.c                |  90 ++++++-
 include/linux/psp-platform-access.h        |   4 +
 include/uapi/linux/psp-dbc.h               | 147 ++++++++++++
 tools/crypto/ccp/.gitignore                |   1 +
 tools/crypto/ccp/dbc.py                    |  98 ++++++++
 tools/crypto/ccp/dbc_cli.py                | 123 ++++++++++
 tools/crypto/ccp/test_dbc.py               | 266 +++++++++++++++++++++
 15 files changed, 1074 insertions(+), 17 deletions(-)
 create mode 100644 drivers/crypto/ccp/dbc.c
 create mode 100644 drivers/crypto/ccp/dbc.h
 create mode 100644 include/uapi/linux/psp-dbc.h
 create mode 100644 tools/crypto/ccp/.gitignore
 create mode 100644 tools/crypto/ccp/dbc.py
 create mode 100755 tools/crypto/ccp/dbc_cli.py
 create mode 100755 tools/crypto/ccp/test_dbc.py


base-commit: 482c84e906e535072c55395acabd3a58e9443d12

Comments

Tom Lendacky April 20, 2023, 7:17 p.m. UTC | #1 
On 4/20/23 11:31, Mario Limonciello wrote:
> As it's not always obvious what PSP bootloader or TEE version are
> present in OEM systems, add the ability to get this information from
> sysfs for supported platforms.
> 
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> ---
>   Documentation/ABI/testing/sysfs-driver-ccp | 18 +++++++
>   drivers/crypto/ccp/sp-dev.h                |  2 +
>   drivers/crypto/ccp/sp-pci.c                | 58 ++++++++++++++++++++++
>   3 files changed, 78 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-driver-ccp b/Documentation/ABI/testing/sysfs-driver-ccp
> index 7aded9b75553..ee6b787eee7a 100644
> --- a/Documentation/ABI/testing/sysfs-driver-ccp
> +++ b/Documentation/ABI/testing/sysfs-driver-ccp
> @@ -85,3 +85,21 @@ Description:
>   		Possible values:
>   		0: Not enforced
>   		1: Enforced
> +
> +What:		/sys/bus/pci/devices/<BDF>/bootloader_version
> +Date:		June 2023
> +KernelVersion:	6.4
> +Contact:	mario.limonciello@amd.com
> +Description:
> +		The /sys/bus/pci/devices/<BDF>/bootloader_version
> +		file reports the firmware version of the AMD AGESA
> +		bootloader.
> +
> +What:		/sys/bus/pci/devices/<BDF>/tee_version
> +Date:		June 2023
> +KernelVersion:	6.4
> +Contact:	mario.limonciello@amd.com
> +Description:
> +		The /sys/bus/pci/devices/<BDF>/tee_version
> +		file reports the firmware version of the AMD Trusted
> +		Execution Environment (TEE).
> diff --git a/drivers/crypto/ccp/sp-dev.h b/drivers/crypto/ccp/sp-dev.h
> index 1253a0217985..76c32ee6bd65 100644
> --- a/drivers/crypto/ccp/sp-dev.h
> +++ b/drivers/crypto/ccp/sp-dev.h
> @@ -51,6 +51,7 @@ struct tee_vdata {
>   	const unsigned int cmdbuff_addr_hi_reg;
>   	const unsigned int ring_wptr_reg;
>   	const unsigned int ring_rptr_reg;
> +	const unsigned int info_reg;
>   };
>   
>   struct platform_access_vdata {
> @@ -69,6 +70,7 @@ struct psp_vdata {
>   	const unsigned int feature_reg;
>   	const unsigned int inten_reg;
>   	const unsigned int intsts_reg;
> +	const unsigned int bootloader_info_reg;
>   };
>   
>   /* Structure to hold SP device data */
> diff --git a/drivers/crypto/ccp/sp-pci.c b/drivers/crypto/ccp/sp-pci.c
> index 85e3dc8853e2..4d729aa1b260 100644
> --- a/drivers/crypto/ccp/sp-pci.c
> +++ b/drivers/crypto/ccp/sp-pci.c
> @@ -8,6 +8,7 @@
>    * Author: Gary R Hook <gary.hook@amd.com>
>    */
>   
> +#include <linux/bitfield.h>
>   #include <linux/module.h>
>   #include <linux/kernel.h>
>   #include <linux/device.h>
> @@ -88,8 +89,65 @@ static struct attribute_group psp_security_attr_group = {
>   	.is_visible = psp_security_is_visible,
>   };
>   
> +#define version_attribute_show(name, _offset)					\
> +static ssize_t name##_show(struct device *d, struct device_attribute *attr,	\
> +			   char *buf)						\
> +{										\
> +	struct sp_device *sp = dev_get_drvdata(d);				\
> +	struct psp_device *psp = sp->psp_data;					\
> +	unsigned int val = ioread32(psp->io_regs + _offset);			\
> +	return sysfs_emit(buf, "%02lx.%02lx.%02lx.%02lx\n",			\
> +			  FIELD_GET(GENMASK(31, 24), val),			\
> +			  FIELD_GET(GENMASK(23, 16), val),			\
> +			  FIELD_GET(GENMASK(15, 8), val),			\
> +			  FIELD_GET(GENMASK(7, 0), val));			\
> +}
> +
> +version_attribute_show(bootloader_version, psp->vdata->bootloader_info_reg)
> +static DEVICE_ATTR_RO(bootloader_version);
> +version_attribute_show(tee_version, psp->vdata->tee->info_reg)
> +static DEVICE_ATTR_RO(tee_version);
> +
> +static struct attribute *psp_firmware_attrs[] = {
> +	&dev_attr_bootloader_version.attr,
> +	&dev_attr_tee_version.attr,
> +	NULL,
> +};
> +
> +static umode_t psp_firmware_is_visible(struct kobject *kobj, struct attribute *attr, int idx)
> +{
> +	struct device *dev = kobj_to_dev(kobj);
> +	struct sp_device *sp = dev_get_drvdata(dev);
> +	struct psp_device *psp = sp->psp_data;
> +	unsigned int val = 0xffffffff;
> +
> +	if (!psp)
> +		return 0;
> +
> +	if (attr == &dev_attr_bootloader_version.attr &&
> +	    psp->vdata->bootloader_info_reg)
> +		val = ioread32(psp->io_regs + psp->vdata->bootloader_info_reg);
> +
> +	if (attr == &dev_attr_tee_version.attr &&
> +	    psp->capability & PSP_CAPABILITY_TEE &&
> +	    psp->vdata->tee->info_reg)
> +		val = ioread32(psp->io_regs + psp->vdata->tee->info_reg);
> +
> +

Extra blank line.

Also, add a comment about how the PSP security policy might block access 
to these areas resulting in reading all f's, so this hides the sysfs 
attribute in that case.

Thanks,
Tom

> +	if (val != 0xffffffff)
> +		return 0444;
> +
> +	return 0;
> +}
> +
> +static struct attribute_group psp_firmware_attr_group = {
> +	.attrs = psp_firmware_attrs,
> +	.is_visible = psp_firmware_is_visible,
> +};
> +
>   static const struct attribute_group *psp_groups[] = {
>   	&psp_security_attr_group,
> +	&psp_firmware_attr_group,
>   	NULL,
>   };
>
Pavel Machek July 15, 2023, 6:23 a.m. UTC | #2 
On Wed 2023-04-26 09:43:43, Mario Limonciello wrote:
> 
> On 4/26/23 08:47, Pavel Machek wrote:
> > Hi!
> > 
> > > Dynamic boost control is a feature of some SoCs that allows
> > > an authenticated entity to send commands to the security processor
> > > to control certain SOC characteristics with the intention to improve
> > > performance.
> > > 
> > > This is implemented via a mechanism that a userspace application would
> > > authenticate using a nonce and key exchange over an IOCTL interface.
> > > 
> > > After authentication is complete an application can exchange signed
> > > messages with the security processor and both ends can validate the
> > > data transmitted.
> > Why is this acceptable? This precludes cross-platform interfaces,
> > right? Why would application want to validate data from PSP? That
> > precludes virtualization, right?
> > 
> > Just put the key in kernel. Users have right to control their own
> > hardware.
> > 							Pavel
> 
> This matches exactly how the interface works in Windows as well.

Windows has different design constrants.

> The reason for validating the data from the PSP is because the data
> crosses multiple trust boundaries and this ensures that the application
> can trust it to make informed decisions.

If the application can not trust kernel, you are already doomed on
Linux.

									Pavel