This RFC series introduces the op-tee based EFI Runtime Variable
Service.
The eMMC device is typically owned by the non-secure world(linux in
this case). There is an existing solution utilizing eMMC RPMB partition
for EFI Variables, it is implemented by interacting with
OP-TEE, StandaloneMM(as EFI Variable Service Pseudo TA), eMMC driver
and tee-supplicant. The last piece is the tee-based variable access
driver to interact with OP-TEE and StandaloneMM.
Masahisa Kojima (2):
efi: expose efivar generic ops register function
tee: Add op-tee helper functions for variable access
drivers/firmware/efi/efi.c | 12 +
drivers/tee/optee/Kconfig | 10 +
drivers/tee/optee/Makefile | 1 +
drivers/tee/optee/mm_communication.h | 249 +++++++++++
drivers/tee/optee/optee_private.h | 5 +-
drivers/tee/optee/optee_stmm_efi.c | 598 +++++++++++++++++++++++++++
drivers/tee/tee_core.c | 23 ++
include/linux/efi.h | 4 +
include/linux/tee_drv.h | 23 ++
9 files changed, 924 insertions(+), 1 deletion(-)
create mode 100644 drivers/tee/optee/mm_communication.h
create mode 100644 drivers/tee/optee/optee_stmm_efi.c
--
2.30.2
The i2c-designware-amdpsp driver communicates with a platform
features mailbox provided by the PSP. The address used for
communication is discovered via a non-architecturally
guaranteed mechanism.
To better scale, export a feature for communication with platform
features directly from the ccp driver.
Mario Limonciello (6):
crypto: ccp: Drop TEE support for IRQ handler
crypto: ccp: Add a header for multiple drivers to use `__psp_pa`
crypto: ccp: Move some PSP mailbox bit definitions into common header
crypto: ccp: Add support for an interface for platform features
crypto: ccp: Enable platform access interface on client PSP parts
i2c: designware: Use PCI PSP driver for communication
arch/x86/kvm/svm/sev.c | 1 +
drivers/crypto/ccp/Makefile | 3 +-
drivers/crypto/ccp/platform-access.c | 166 ++++++++++++++++++++
drivers/crypto/ccp/platform-access.h | 34 ++++
drivers/crypto/ccp/psp-dev.c | 32 ++--
drivers/crypto/ccp/psp-dev.h | 11 +-
drivers/crypto/ccp/sev-dev.c | 16 +-
drivers/crypto/ccp/sev-dev.h | 2 +-
drivers/crypto/ccp/sp-dev.h | 7 +
drivers/crypto/ccp/sp-pci.c | 7 +
drivers/crypto/ccp/tee-dev.c | 17 +-
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-designware-amdpsp.c | 149 +-----------------
drivers/i2c/busses/i2c-designware-core.h | 1 -
drivers/i2c/busses/i2c-designware-platdrv.c | 1 -
drivers/tee/amdtee/call.c | 2 +-
drivers/tee/amdtee/shm_pool.c | 2 +-
include/linux/psp-platform-access.h | 50 ++++++
include/linux/psp-sev.h | 8 -
include/linux/psp.h | 26 +++
20 files changed, 340 insertions(+), 197 deletions(-)
create mode 100644 drivers/crypto/ccp/platform-access.c
create mode 100644 drivers/crypto/ccp/platform-access.h
create mode 100644 include/linux/psp-platform-access.h
create mode 100644 include/linux/psp.h
base-commit: c7410b425de40e9b163eef781e1bdacf1bf2962e
--
2.34.1
Sumit,
I did not see a follow up on this series per your last email.[1] I'd like to
move forward with getting rid of kmap_to_page(). So Hopefully this can land
and you can build on this rather than the other way around?
All,
Al Viro found[2] that kmap_to_page() is broken. But not only is it broken, it
presents confusion over how highmem should be used because kmap() and friends
should not be used for 'long term' mappings.
get_kernel_pages() is a caller of kmap_to_page(). It only has one caller
[shm_get_kernel_pages()] which does not need the functionality.
Alter shm_get_kernel_pages() to no longer call get_kernel_pages() and remove
get_kernel_pages(). Along the way it was noted that shm_get_kernel_pages()
does not have any need to support vmalloc'ed addresses either. Remove that
functionality to clean up the logic.
This series also fixes is_kmap_addr() and uses it to ensure no kmap addresses
slip in later.
[1] https://lore.kernel.org/all/CAFA6WYMqEVDVW-ifoh-V9ni1zntYdes8adQKf2XXAUpqda…
[2] https://lore.kernel.org/lkml/YzSSl1ItVlARDvG3@ZenIV
To: Sumit Garg <sumit.garg(a)linaro.org>
To: Andrew Morton <akpm(a)linux-foundation.org>
Cc: "Al Viro" <viro(a)zeniv.linux.org.uk>
Cc: "Christoph Hellwig" <hch(a)lst.de>
Cc: linux-kernel(a)vger.kernel.org
Cc: op-tee(a)lists.trustedfirmware.org
Cc: linux-mm(a)kvack.org
Cc: Jens Wiklander <jens.wiklander(a)linaro.org>
Cc: "Fabio M. De Francesco" <fmdefrancesco(a)gmail.com>
Signed-off-by: Ira Weiny <ira.weiny(a)intel.com>
---
Changes in v2:
- Al Viro: Avoid allocating the kiov.
- Sumit: Update cover letter to clarify the motivation behind removing
get_kernel_pages()
- Link to v1: https://lore.kernel.org/r/20221002002326.946620-1-ira.weiny@intel.com
---
Ira Weiny (4):
highmem: Enhance is_kmap_addr() to check kmap_local_page() mappings
tee: Remove vmalloc page support
tee: Remove call to get_kernel_pages()
mm: Remove get_kernel_pages()
drivers/tee/tee_shm.c | 37 ++++++++++---------------------------
include/linux/highmem-internal.h | 5 ++++-
include/linux/mm.h | 2 --
mm/swap.c | 30 ------------------------------
4 files changed, 14 insertions(+), 60 deletions(-)
---
base-commit: 0136d86b78522bbd5755f8194c97a987f0586ba5
change-id: 20230203-get_kernel_pages-199342cfba79
Best regards,
--
Ira Weiny <ira.weiny(a)intel.com>
Add a new ioctl called TEE_IOC_SHM_REGISTER_FD to register a
shared memory from a dmabuf file descriptor.
This new ioctl will allow the Linux Kernel to register a buffer
to be used by the Secure Data Path OPTEE OS feature.
Please find more information here:
https://static.linaro.org/connect/san19/presentations/san19-107.pdf
Patch tested on Hikey 6220.
Etienne Carriere (1):
tee: new ioctl to a register tee_shm from a dmabuf file descriptor
drivers/tee/tee_core.c | 38 +++++++++++++++
drivers/tee/tee_shm.c | 99 +++++++++++++++++++++++++++++++++++++++-
include/linux/tee_drv.h | 11 +++++
include/uapi/linux/tee.h | 29 ++++++++++++
4 files changed, 175 insertions(+), 2 deletions(-)
--
2.25.0
What's the current state of being able to log to the REE using components
that already exist in OP-TEE today? I've seen various issues relating to
it in GitHub: https://github.com/OP-TEE/optee_os/issues/4230 and
https://github.com/OP-TEE/optee_os/pull/810, but both ended up being closed
before I can see anything relating to logging to integrated. Did something
like this end up getting implemented yet?
Cheers,
--
Jeffrey Kardatzke
jkardatzke(a)google.com
Google, Inc.