This patch series introduces Trusted Execution Environment (TEE) driver
for AMD APU enabled systems. The TEE is a secure area of a processor which
ensures that sensitive data is stored, processed and protected in an
isolated and trusted environment. The AMD Secure Processor is a dedicated
processor which provides TEE to enable HW platform security. It offers
protection against software attacks generated in Rich Operating
System (Rich OS) such as Linux running on x86. The AMD-TEE Trusted OS
running on AMD Secure Processor allows loading and execution of security
sensitive applications called Trusted Applications (TAs). An example of
a TA would be a DRM (Digital Rights Management) TA written to enforce
content protection.
Linux already provides a tee subsystem, which is described in [1]. The tee
subsystem provides a generic TEE ioctl interface which can be used by user
space to talk to a TEE driver. AMD-TEE driver registers with tee subsystem
and implements tee function callbacks in an AMD platform specific manner.
The following TEE commands are recognized by AMD-TEE Trusted OS:
1. TEE_CMD_ID_LOAD_TA : Load Trusted Application (TA) binary into TEE
environment
2. TEE_CMD_ID_UNLOAD_TA : Unload TA binary from TEE environment
3. TEE_CMD_ID_OPEN_SESSION : Open session with loaded TA
4. TEE_CMD_ID_CLOSE_SESSION : Close session with loaded TA
5. TEE_CMD_ID_INVOKE_CMD : Invoke a command with loaded TA
6. TEE_CMD_ID_MAP_SHARED_MEM : Map shared memory
7. TEE_CMD_ID_UNMAP_SHARED_MEM : Unmap shared memory
Each command has its own payload format. The AMD-TEE driver creates a
command buffer payload for submission to AMD-TEE Trusted OS. The driver
uses the services of AMD Secure Processor driver to submit commands
to the Trusted OS. Further details can be found in [1].
This patch series is based on cryptodev-2.6 tree with base commit
c6d633a92749 (crypto: algapi - make unregistration functions return void).
[1] https://www.kernel.org/doc/Documentation/tee.txt
Rijo Thomas (4):
tee: allow compilation of tee subsystem for AMD CPUs
tee: add AMD-TEE driver
tee: amdtee: check TEE status during driver initialization
Documentation: tee: add AMD-TEE driver details
Documentation/tee.txt | 81 ++++++
drivers/crypto/ccp/tee-dev.c | 11 +
drivers/tee/Kconfig | 4 +-
drivers/tee/Makefile | 1 +
drivers/tee/amdtee/Kconfig | 8 +
drivers/tee/amdtee/Makefile | 5 +
drivers/tee/amdtee/amdtee_if.h | 183 +++++++++++++
drivers/tee/amdtee/amdtee_private.h | 159 +++++++++++
drivers/tee/amdtee/call.c | 373 ++++++++++++++++++++++++++
drivers/tee/amdtee/core.c | 516 ++++++++++++++++++++++++++++++++++++
drivers/tee/amdtee/shm_pool.c | 93 +++++++
include/linux/psp-tee.h | 18 ++
include/uapi/linux/tee.h | 1 +
13 files changed, 1451 insertions(+), 2 deletions(-)
create mode 100644 drivers/tee/amdtee/Kconfig
create mode 100644 drivers/tee/amdtee/Makefile
create mode 100644 drivers/tee/amdtee/amdtee_if.h
create mode 100644 drivers/tee/amdtee/amdtee_private.h
create mode 100644 drivers/tee/amdtee/call.c
create mode 100644 drivers/tee/amdtee/core.c
create mode 100644 drivers/tee/amdtee/shm_pool.c
--
1.9.1
Hi,
I've been hunting down some hackbench regression between 5.4-rc8 and 5.5-rc1
on my Juno r0, one of the offenders seems to be:
246880958ac9 ("firmware: broadcom: add OP-TEE based BNXT f/w manager")
This is tested on a kernel built with defconfig (TEE_BNXT_FW gets selected)
and with:
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
./perf stat --null --sync --repeat 200 ./hackbench
The regression is easily reproducible on my end, this is 3 runs of the above
comparing the patch and its parent:
-PATCH:
0.71062 +- 0.00150 seconds time elapsed ( +- 0.21% )
0.71121 +- 0.00181 seconds time elapsed ( +- 0.25% )
0.71277 +- 0.00181 seconds time elapsed ( +- 0.25% )
+PATCH:
0.72556 +- 0.00174 seconds time elapsed ( +- 0.24% )
0.72695 +- 0.00192 seconds time elapsed ( +- 0.26% )
0.72559 +- 0.00178 seconds time elapsed ( +- 0.25% )
AIUI Vincent found something different while hunting down a similar
regression:
df323337e507 ("apparmor: Use a memory pool instead per-CPU caches")
but it seems this one is another cause. Seeing as this involves security
stuff the overhead may be acceptable, nevertheless now that I have some
reproducer I figured I'd send this out.
Cheers,
Valentin
This patch series introduces Trusted Execution Environment (TEE) driver
for AMD APU enabled systems. The TEE is a secure area of a processor which
ensures that sensitive data is stored, processed and protected in an
isolated and trusted environment. The AMD Secure Processor is a dedicated
processor which provides TEE to enable HW platform security. It offers
protection against software attacks generated in Rich Operating
System (Rich OS) such as Linux running on x86. The AMD-TEE Trusted OS
running on AMD Secure Processor allows loading and execution of security
sensitive applications called Trusted Applications (TAs). An example of
a TA would be a DRM (Digital Rights Management) TA written to enforce
content protection.
Linux already provides a tee subsystem, which is described in [1]. The tee
subsystem provides a generic TEE ioctl interface which can be used by user
space to talk to a TEE driver. AMD-TEE driver registers with tee subsystem
and implements tee function callbacks in an AMD platform specific manner.
The following TEE commands are recognized by AMD-TEE Trusted OS:
1. TEE_CMD_ID_LOAD_TA : Load Trusted Application (TA) binary into TEE
environment
2. TEE_CMD_ID_UNLOAD_TA : Unload TA binary from TEE environment
3. TEE_CMD_ID_OPEN_SESSION : Open session with loaded TA
4. TEE_CMD_ID_CLOSE_SESSION : Close session with loaded TA
5. TEE_CMD_ID_INVOKE_CMD : Invoke a command with loaded TA
6. TEE_CMD_ID_MAP_SHARED_MEM : Map shared memory
7. TEE_CMD_ID_UNMAP_SHARED_MEM : Unmap shared memory
Each command has its own payload format. The AMD-TEE driver creates a
command buffer payload for submission to AMD-TEE Trusted OS.
This patch series has a dependency on another patch set titled - Add TEE
interface support to AMD Secure Processor driver.
Link: https://lkml.org/lkml/2019/12/4/42
v3:
* Updated [1] with driver details
v2:
* Added a helper API in AMD Secure Processor driver, which can be
called by AMD-TEE driver during module init to check if TEE is
present on the device
* Added proper checks for parameter attribute variable
* Used tee_shm_pool_alloc() to allocate struct tee_shm_pool data structure
* Removed all references to tee_private.h header file in driver code,
except for the file drivers/tee/amdtee/core.c. The driver loads TA binary
by calling request_firmware(), which takes struct device* as one of its
arguments. The device 'dev' field is part of struct tee_device, defined
in tee_private.h
[1] https://www.kernel.org/doc/Documentation/tee.txt
Rijo Thomas (4):
tee: allow compilation of tee subsystem for AMD CPUs
tee: add AMD-TEE driver
tee: amdtee: check TEE status during driver initialization
Documentation: tee: add AMD-TEE driver details
Documentation/tee.txt | 81 ++++++
drivers/crypto/ccp/tee-dev.c | 11 +
drivers/tee/Kconfig | 4 +-
drivers/tee/Makefile | 1 +
drivers/tee/amdtee/Kconfig | 8 +
drivers/tee/amdtee/Makefile | 5 +
drivers/tee/amdtee/amdtee_if.h | 183 +++++++++++++
drivers/tee/amdtee/amdtee_private.h | 159 +++++++++++
drivers/tee/amdtee/call.c | 373 ++++++++++++++++++++++++++
drivers/tee/amdtee/core.c | 516 ++++++++++++++++++++++++++++++++++++
drivers/tee/amdtee/shm_pool.c | 93 +++++++
include/linux/psp-tee.h | 18 ++
include/uapi/linux/tee.h | 1 +
13 files changed, 1451 insertions(+), 2 deletions(-)
create mode 100644 drivers/tee/amdtee/Kconfig
create mode 100644 drivers/tee/amdtee/Makefile
create mode 100644 drivers/tee/amdtee/amdtee_if.h
create mode 100644 drivers/tee/amdtee/amdtee_private.h
create mode 100644 drivers/tee/amdtee/call.c
create mode 100644 drivers/tee/amdtee/core.c
create mode 100644 drivers/tee/amdtee/shm_pool.c
--
1.9.1
This patch series introduces Trusted Execution Environment (TEE) driver
for AMD APU enabled systems. The TEE is a secure area of a processor which
ensures that sensitive data is stored, processed and protected in an
isolated and trusted environment. The AMD Secure Processor is a dedicated
processor which provides TEE to enable HW platform security. It offers
protection against software attacks generated in Rich Operating
System (Rich OS) such as Linux running on x86. The AMD-TEE Trusted OS
running on AMD Secure Processor allows loading and execution of security
sensitive applications called Trusted Applications (TAs). An example of
a TA would be a DRM (Digital Rights Management) TA written to enforce
content protection.
Linux already provides a tee subsystem, which is described in [1]. The tee
subsystem provides a generic TEE ioctl interface which can be used by user
space to talk to a TEE driver. AMD-TEE driver registers with tee subsystem
and implements tee function callbacks in an AMD platform specific manner.
The following TEE commands are recognized by AMD-TEE Trusted OS:
1. TEE_CMD_ID_LOAD_TA : Load Trusted Application (TA) binary into TEE
environment
2. TEE_CMD_ID_UNLOAD_TA : Unload TA binary from TEE environment
3. TEE_CMD_ID_OPEN_SESSION : Open session with loaded TA
4. TEE_CMD_ID_CLOSE_SESSION : Close session with loaded TA
5. TEE_CMD_ID_INVOKE_CMD : Invoke a command with loaded TA
6. TEE_CMD_ID_MAP_SHARED_MEM : Map shared memory
7. TEE_CMD_ID_UNMAP_SHARED_MEM : Unmap shared memory
Each command has its own payload format. The AMD-TEE driver creates a
command buffer payload for submission to AMD-TEE Trusted OS.
I shall update [1] with AMD-TEE driver details shortly.
This patch series has a dependency on another patch set titled - Add TEE
interface support to AMD Secure Processor driver.
Link:
https://patchwork.kernel.org/project/linux-crypto/list/?submitter=188843
v2:
* Added a helper API in AMD Secure Processor driver, which can be
called by AMD-TEE driver during module init to check if TEE is
present on the device
* Added proper checks for parameter attribute variable
* Used tee_shm_pool_alloc() to allocate struct tee_shm_pool data structure
* Removed all references to tee_private.h header file in driver code,
except for the file drivers/tee/amdtee/core.c. The driver loads TA binary
by calling request_firmware(), which takes struct device* as one of its
arguments. The device 'dev' field is part of struct tee_device, defined
in tee_private.h
[1] https://www.kernel.org/doc/Documentation/tee.txt
Rijo Thomas (3):
tee: allow compilation of tee subsystem for AMD CPUs
tee: add AMD-TEE driver
tee: amdtee: check TEE status during driver initialization
drivers/crypto/ccp/tee-dev.c | 11 +
drivers/tee/Kconfig | 4 +-
drivers/tee/Makefile | 1 +
drivers/tee/amdtee/Kconfig | 8 +
drivers/tee/amdtee/Makefile | 5 +
drivers/tee/amdtee/amdtee_if.h | 183 +++++++++++++
drivers/tee/amdtee/amdtee_private.h | 159 +++++++++++
drivers/tee/amdtee/call.c | 373 ++++++++++++++++++++++++++
drivers/tee/amdtee/core.c | 516 ++++++++++++++++++++++++++++++++++++
drivers/tee/amdtee/shm_pool.c | 93 +++++++
include/linux/psp-tee.h | 18 ++
include/uapi/linux/tee.h | 1 +
12 files changed, 1370 insertions(+), 2 deletions(-)
create mode 100644 drivers/tee/amdtee/Kconfig
create mode 100644 drivers/tee/amdtee/Makefile
create mode 100644 drivers/tee/amdtee/amdtee_if.h
create mode 100644 drivers/tee/amdtee/amdtee_private.h
create mode 100644 drivers/tee/amdtee/call.c
create mode 100644 drivers/tee/amdtee/core.c
create mode 100644 drivers/tee/amdtee/shm_pool.c
--
1.9.1