This series introduces the 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.
Changelog:
v5 -> v6
- new patch #4 is added in this series, #1-#3 patches are unchanged.
automatically update super block flag when the efivarops support
SetVariable runtime service, so that user does not need to manually
remount the efivarfs as RW.
v4 -> v5
- rebase to efi-next based on v6.4-rc1
- set generic_ops.query_variable_info, it works as expected as follows.
$ df -h /sys/firmware/efi/efivars/
Filesystem Size Used Avail Use% Mounted on
efivarfs 16K 1.3K 15K 8% /sys/firmware/efi/efivars
v3 -> v4:
- replace the reference from EDK2 to PI Specification
- remove EDK2 source code reference comments
- prepare nonblocking variant of set_variable, it just returns
EFI_UNSUPPORTED
- remove redundant buffer size check
- argument name change in mm_communicate
- function interface changes in setup_mm_hdr to remove (void **) cast
v2 -> v3:
- add CONFIG_EFI dependency to TEE_STMM_EFI
- add missing return code check for tee_client_invoke_func()
- directly call efivars_register/unregister from tee_stmm_efi.c
rfc v1 -> v2:
- split patch into three patches, one for drivers/tee,
one for include/linux/efi.h, and one for the driver/firmware/efi/stmm
- context/session management into probe() and remove() same as other tee
client driver
- StMM variable driver is moved from driver/tee/optee to driver/firmware/efi
- use "tee" prefix instead of "optee" in driver/firmware/efi/stmm/tee_stmm_efi.c,
this file does not contain op-tee specific code, abstracted by tee layer and
StMM variable driver will work on other tee implementation.
- PTA_STMM_CMD_COMMUNICATE -> PTA_STMM_CMD_COMMUNICATE
- implement query_variable_store() but currently not used
- no use of TEEC_SUCCESS, it is defined in driver/tee/optee/optee_private.h.
Other tee client drivers use 0 instead of using TEEC_SUCCESS
- remove TEEC_ERROR_EXCESS_DATA status, it is referred just to output
error message
Masahisa Kojima (4):
efi: expose efivar generic ops register function
efi: Add EFI_ACCESS_DENIED status code
efi: Add tee-based EFI variable driver
efivarfs: automatically update super block flag
drivers/firmware/efi/Kconfig | 15 +
drivers/firmware/efi/Makefile | 1 +
drivers/firmware/efi/efi.c | 18 +
drivers/firmware/efi/stmm/mm_communication.h | 236 +++++++
drivers/firmware/efi/stmm/tee_stmm_efi.c | 638 +++++++++++++++++++
drivers/firmware/efi/vars.c | 8 +
fs/efivarfs/super.c | 33 +
include/linux/efi.h | 12 +
8 files changed, 961 insertions(+)
create mode 100644 drivers/firmware/efi/stmm/mm_communication.h
create mode 100644 drivers/firmware/efi/stmm/tee_stmm_efi.c
base-commit: d0a1865cf7e2211d9227592ef4141f4632e33908
--
2.30.2
[BCC all OP-TEE maintainers]
Hi OP-TEE maintainers & contributors,
OP-TEE v3.22.0 is scheduled to be released at 2023-07-07 (*). So, now is
a good time to start testing the master branch on the various platforms
and report/fix any bugs.
The GitHub pull request for collecting Tested-by tags or any other
comments is https://github.com/OP-TEE/optee_os/pull/6125.
As usual, we will create a release candidate tag one week before the
release date for final testing.
In addition to that you can find some additional information related to
releases here: https://optee.readthedocs.io/en/latest/general/releases.html
Regards,
Joakim Bech
(*) We moved this from July 14th to July 7th due to vacation and holiday
schedules.
Hi,
I contact you about the merge request
https://github.com/OP-TEE/optee_os/pull/5166 that is mandatory to be able
to use ECC private key imported in PKCS11 TA and not generate by the TA.
Currently the status is
Attribute on generated ECC private key are
- EC_PARAMS
- VALUE
- EC_POINT
=> This object can be use for crypto operation
Attribute on imported ECC private key are
- EC_PARAMS
- VALUE
=> PKCS11 TA can not use it because TA expect EC_POINTS attributes on ECC
Private key.
Could you accept the merge request and have a coherence between generated
and imported object even if for the moment it's doesn't respect PKCS11
standard ?
Two options for the next step.
- check with PKCS11 editors to upgrade the spec and have a same behavior
between RSA Private object and ECC Private object.
- rework the code of the TA for ECC to link Private and public object but
that mean that ECC Private and Public object must be present in the same
slot to be able to perform crypto operation.
Best regards,
Cédric Dourlent,
Hello arm-soc maintainers,
Please pull this small patch to the OP-TEE driver that replaces
kmalloc() + memcpy() with kmemdup() at one place.
Thanks,
Jens
The following changes since commit f1fcbaa18b28dec10281551dfe6ed3a3ed80e3d6:
Linux 6.4-rc2 (2023-05-14 12:51:40 -0700)
are available in the Git repository at:
https://git.linaro.org/people/jens.wiklander/linux-tee.git tags/optee-use-kmemdup-for-6.5
for you to fetch changes up to 6a8b7e80105416cc7324fda295608ea2d3f98862:
tee: optee: Use kmemdup() to replace kmalloc + memcpy (2023-06-15 08:49:55 +0200)
----------------------------------------------------------------
Use kmemdup() in OP-TEE driver
----------------------------------------------------------------
Jiapeng Chong (1):
tee: optee: Use kmemdup() to replace kmalloc + memcpy
drivers/tee/optee/smc_abi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)