- OP-TEE - lists.trustedfirmware.org

[RFC, PATCH 0/1] Replay Protected Memory Block (RPMB) driver

by Shyam Saini

Hi everyone, This is yet another attempt to come up with an RPMB API for the kernel. This patch is based on patch 1 of last submission except few minor changes. The last discussion of this was in the thread: Subject: [PATCH v2 1/4] rpmb: add Replay Protected Memory Block (RPMB) subsystem Date: Tue, 5 Apr 2022 10:37:56 +0100 [thread overview] Message-ID: <20220405093759.1126835-2-alex.bennee(a)linaro.org> The patch provides a simple RPMB driver. This is a RFC version and this single driver can't be used by its own. It would require further work to make use of API's provided by this driver. Changes since the last posting: drop RPMB char driver drop virtio rpmb frontend driver drop rpmb: add RPBM access tool Rename get_write_count to get_write_counter Make return type for rpmb_set_key() function explicit Alex Bennée (1): rpmb: add Replay Protected Memory Block (RPMB) driver MAINTAINERS | 7 + drivers/Kconfig | 1 + drivers/Makefile | 2 + drivers/rpmb/Kconfig | 11 ++ drivers/rpmb/Makefile | 7 + drivers/rpmb/core.c | 439 ++++++++++++++++++++++++++++++++++++++++++ include/linux/rpmb.h | 182 +++++++++++++++++ 7 files changed, 649 insertions(+) create mode 100644 drivers/rpmb/Kconfig create mode 100644 drivers/rpmb/Makefile create mode 100644 drivers/rpmb/core.c create mode 100644 include/linux/rpmb.h -- 2.34.1

2 years, 9 months

9
20
0 0

[PATCH] KEYS: trusted: tee: use tee_shm_register_alloc_buf()

by Jens Wiklander

Prior to this patch was trusted_tee_seal() and trusted_tee_get_random() relying on tee_shm_register_kernel_buf() to share memory with the TEE. Depending on the memory allocation pattern the pages holding the registered buffers overlap with other buffers also shared with the TEE. The OP-TEE driver using the old SMC based ABI permits overlapping shared buffers, but with the new FF-A based ABI each physical page may only be registered once. Fix this problem by allocating a temporary page aligned shared memory buffer to be used as a bounce buffer for the needed data buffers. Since TEE trusted keys doesn't depend on registered shared memory support any longer remove that explicit dependency when opening a context to the TEE. Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org> --- security/keys/trusted-keys/trusted_tee.c | 68 +++++++++++++----------- 1 file changed, 36 insertions(+), 32 deletions(-) diff --git a/security/keys/trusted-keys/trusted_tee.c b/security/keys/trusted-keys/trusted_tee.c index ac3e270ade69..3085343c489a 100644 --- a/security/keys/trusted-keys/trusted_tee.c +++ b/security/keys/trusted-keys/trusted_tee.c @@ -8,6 +8,7 @@ #include <linux/err.h> #include <linux/key-type.h> +#include <linux/minmax.h> #include <linux/module.h> #include <linux/slab.h> #include <linux/string.h> @@ -65,38 +66,37 @@ static int trusted_tee_seal(struct trusted_key_payload *p, char *datablob) int ret; struct tee_ioctl_invoke_arg inv_arg; struct tee_param param[4]; - struct tee_shm *reg_shm_in = NULL, *reg_shm_out = NULL; + struct tee_shm *shm; + uint8_t *buf; memset(&inv_arg, 0, sizeof(inv_arg)); memset(&param, 0, sizeof(param)); - reg_shm_in = tee_shm_register_kernel_buf(pvt_data.ctx, p->key, - p->key_len); - if (IS_ERR(reg_shm_in)) { - dev_err(pvt_data.dev, "key shm register failed\n"); - return PTR_ERR(reg_shm_in); + shm = tee_shm_alloc_kernel_buf(pvt_data.ctx, + p->key_len + sizeof(p->blob)); + if (IS_ERR(shm)) { + dev_err(pvt_data.dev, "key shm alloc failed\n"); + return PTR_ERR(shm); } - - reg_shm_out = tee_shm_register_kernel_buf(pvt_data.ctx, p->blob, - sizeof(p->blob)); - if (IS_ERR(reg_shm_out)) { - dev_err(pvt_data.dev, "blob shm register failed\n"); - ret = PTR_ERR(reg_shm_out); + buf = tee_shm_get_va(shm, 0); + if (IS_ERR(buf)) { + ret = PTR_ERR(buf); goto out; } + memcpy(buf, p->key, p->key_len); inv_arg.func = TA_CMD_SEAL; inv_arg.session = pvt_data.session_id; inv_arg.num_params = 4; param[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT; - param[0].u.memref.shm = reg_shm_in; + param[0].u.memref.shm = shm; param[0].u.memref.size = p->key_len; param[0].u.memref.shm_offs = 0; param[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT; - param[1].u.memref.shm = reg_shm_out; + param[1].u.memref.shm = shm; param[1].u.memref.size = sizeof(p->blob); - param[1].u.memref.shm_offs = 0; + param[1].u.memref.shm_offs = p->key_len; ret = tee_client_invoke_func(pvt_data.ctx, &inv_arg, param); if ((ret < 0) || (inv_arg.ret != 0)) { @@ -104,14 +104,13 @@ static int trusted_tee_seal(struct trusted_key_payload *p, char *datablob) inv_arg.ret); ret = -EFAULT; } else { + memcpy(p->blob, buf + p->key_len, + min(param[1].u.memref.size, sizeof(p->blob))); p->blob_len = param[1].u.memref.size; } out: - if (reg_shm_out) - tee_shm_free(reg_shm_out); - if (reg_shm_in) - tee_shm_free(reg_shm_in); + tee_shm_free(shm); return ret; } @@ -166,11 +165,9 @@ static int trusted_tee_unseal(struct trusted_key_payload *p, char *datablob) p->key_len = param[1].u.memref.size; } + tee_shm_free(reg_shm_out); out: - if (reg_shm_out) - tee_shm_free(reg_shm_out); - if (reg_shm_in) - tee_shm_free(reg_shm_in); + tee_shm_free(reg_shm_in); return ret; } @@ -183,15 +180,21 @@ static int trusted_tee_get_random(unsigned char *key, size_t key_len) int ret; struct tee_ioctl_invoke_arg inv_arg; struct tee_param param[4]; - struct tee_shm *reg_shm = NULL; + struct tee_shm *shm; + void *buf; memset(&inv_arg, 0, sizeof(inv_arg)); memset(&param, 0, sizeof(param)); - reg_shm = tee_shm_register_kernel_buf(pvt_data.ctx, key, key_len); - if (IS_ERR(reg_shm)) { - dev_err(pvt_data.dev, "key shm register failed\n"); - return PTR_ERR(reg_shm); + shm = tee_shm_alloc_kernel_buf(pvt_data.ctx, key_len); + if (IS_ERR(shm)) { + dev_err(pvt_data.dev, "key shm alloc failed\n"); + return PTR_ERR(shm); + } + buf = tee_shm_get_va(shm, 0); + if (IS_ERR(buf)) { + ret = PTR_ERR(buf); + goto out; } inv_arg.func = TA_CMD_GET_RANDOM; @@ -199,7 +202,7 @@ static int trusted_tee_get_random(unsigned char *key, size_t key_len) inv_arg.num_params = 4; param[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT; - param[0].u.memref.shm = reg_shm; + param[0].u.memref.shm = shm; param[0].u.memref.size = key_len; param[0].u.memref.shm_offs = 0; @@ -209,18 +212,19 @@ static int trusted_tee_get_random(unsigned char *key, size_t key_len) inv_arg.ret); ret = -EFAULT; } else { + memcpy(key, buf, min(param[0].u.memref.size, key_len)); ret = param[0].u.memref.size; } - tee_shm_free(reg_shm); +out: + tee_shm_free(shm); return ret; } static int optee_ctx_match(struct tee_ioctl_version_data *ver, const void *data) { - if (ver->impl_id == TEE_IMPL_ID_OPTEE && - ver->gen_caps & TEE_GEN_CAP_REG_MEM) + if (ver->impl_id == TEE_IMPL_ID_OPTEE) return 1; else return 0; -- 2.34.1

2 years, 10 months

2
11
0 0

Linaro OP-TEE Contribution, LOC, monthly meeting August 22

by Jens Wiklander

Hi, Time flies, on Tuesday, August 22 it's for another LOC monthly meeting. For time and connection details see the calendar at https://www.trustedfirmware.org/meetings/ I'm happy to report that the Xen patches needed to run OP-TEE with FF-A have just been merged [1] and will be included in the next Xen release. With this, we may need to focus more on for how long we may hog the CPU with non-secure interrupts masked. [1] https://patchew.org/Xen/20230731121536.934239-1-jens.wiklander@linaro.org/#… Any other topics? Thanks, Jens

2 years, 10 months

1
0
0 0

Run OP-TEE on Morello kernel issue

by Menna Mahmoud

Hi All, I have an issue with running OP-TEE on the Morello kernel, I posted it here: https://github.com/OP-TEE/optee_os/issues/6244 Can anyone help me? Thanks in advance, Menna

2 years, 10 months

1
0
0 0

tpm2 device fail on u-boot

by Ruth Glushkin

Hi, I have u-boot based on u-boot 2021.04 I have configuration with fTPM of Microsoft enabled. I have a EVB board with Nuvoton chip. OPTee-OS is based on latest 3.22 upstream version with Nuvoton npcm platform configuration. If I take OPTee-OS without reading HUK from our PCR0 field from non-secured memory, the command works fine. If I add reading HUK, the command fails. Here is the error log: - U-Boot>tpm2 device optee optee: OP-TEE: revision 3.22 (a012b992) I/TC: Reserved shared memory is enabled I/TC: Dynamic shared memory is enabled I/TC: Normal World virtualization support is disabled I/TC: Asynchronous notifications are disabled E/TC:0 0 std_entry_with_parg:235 Bad arg address 0x7fce2000 Couldn't set TPM 0 (rc = 1) - All other commands of tpm2 that are not connected to fTPM works OK. After loading Linux, xtest works OK. Could you please help me? Thank you in advance, Margarita Glushkin

2 years, 10 months

2
2
0 0

[PATCH v7 0/5] introduce tee-based EFI Runtime Variable Service

by Masahisa Kojima

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: v6 -> v7 Patch #1-#4 are not updated. Patch #5 is added into this series, original patch is here: https://lore.kernel.org/all/20230609094532.562934-1-ilias.apalodimas@linaro… There are two issues in the v6 series and v7 series addresses those. 1) efivar ops is not restored when the tee-supplicant daemon terminates. -> As the following patch says, user must remove the device before terminating tee-supplicant daemon. https://lore.kernel.org/all/20230728134832.326467-1-sumit.garg@linaro.org/ 2) cause panic when someone remounts the efivarfs as RW even if SetVariable is not supported -> The fifth patch addresses this issue. "[PATCH v7 5/5] efivarfs: force RO when remounting if SetVariable is not supported" 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 Ilias Apalodimas (1): efivarfs: force RO when remounting if SetVariable is not supported 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 | 45 ++ include/linux/efi.h | 12 + 8 files changed, 973 insertions(+) create mode 100644 drivers/firmware/efi/stmm/mm_communication.h create mode 100644 drivers/firmware/efi/stmm/tee_stmm_efi.c base-commit: 2e28a798c3092ea42b968fa16ac835969d124898 -- 2.30.2

2 years, 10 months

5
12
0 0

[PATCH v6 0/4] introduce tee-based EFI Runtime Variable Service

by Masahisa Kojima

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

2 years, 10 months

3
16
0 0

OP-TEE 3.22.0 has been released

by Joakim Bech

Hi, I'm pleased to announce that OP-TEE version 3.22.0 is now available. The list of changes can be found in the changelog [1]. The branch for stable can be found here [2]. Tested platforms in this release can be found here [3]. Many thanks to everyone who has contributed in any form to this release. Let me also highlight that because many people are on vacation over the summer, we cancelled the Linaro OP-TEE call for the month of July. Having said that, we have coverage for maintenance tasks and security issues. However, due to the reduced workforce, getting attention for reviewing and merging may take a little longer in the coming weeks. [1] https://github.com/OP-TEE/optee_os/blob/master/CHANGELOG.md [2] https://github.com/OP-TEE/manifest/tree/3.22.0 [3] https://github.com/OP-TEE/optee_os/commit/001ace6655dd6bb9cbe31aa31b4ba6974… -- Regards, Joakim

2 years, 11 months

2
1
0 0

core: fix fragmented memory retrieve

by 梅建强(禹夜)

Hi, Jens, The PR has been updated as requested. https://github.com/OP-TEE/optee_os/pull/5966 <https://github.com/OP-TEE/optee_os/pull/5966 > Regards, Yuye. ------------------------------------------------------------------ 发件人：Jens Wiklander <jens.wiklander(a)linaro.org> 发送时间：2023年7月3日(星期一) 15:20 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：op-tee <op-tee(a)lists.trustedfirmware.org> 主　题：Re: core: fix fragmented memory retrieve Hi Yuye, On Mon, Jul 3, 2023 at 8:30 AM 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> wrote: > > > > > Hi, Jens, > > The previous fix was based on ffa_mem_transaction with ffa version 1.0, > now optee and Hafnium have updated ffa_mem_transaction to ffa 1.1. > But optee-driver in linaro-swg/linux seems to be using ffa version 1.0, > which causes incorrect data reading when the driver is doing mem_share to Hafnium. > I need to debug my previous code. > When will optee-driver synchronize this version change? Updating the SPMC version in the SPMC manifest should fix the issue of mismatching versions. By the way, I've started to update my QEMU S-EL2 setup to use upstream only. I'll propose updates for the manifest and build gits to be merged after the upcoming OP-TEE release. Cheers, Jens > > Regards, > Yuye. > > ------------------------------------------------------------------ > 发件人：Jens Wiklander <jens.wiklander(a)linaro.org> > 发送时间：2023年6月28日(星期三) 17:54 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：op-tee <op-tee(a)lists.trustedfirmware.org> > 主题：Re: core: fix fragmented memory retrieve > > Hi Yuye, > > On Wed, Jun 28, 2023 at 11:50 AM 梅建强(禹夜) > <meijianqiang.mjq(a)alibaba-inc.com> wrote: > > > > > > > > > > Hi, Jens, > > > > Sorry for forgetting to revise the PR in time, because my github email changed so I haven't received any comments. > > Could you help me reopen the PR since I don't have the right? I will re-fix the problem as requested. > > Thanks. > > https://github.com/OP-TEE/optee_os/pull/5966 <https://github.com/OP-TEE/optee_os/pull/5966 > > > I've reopened it. > > Cheers, > Jens

2 years, 11 months

1
0
0 0

core: fix fragmented memory retrieve

by 梅建强(禹夜)

Hi, Jens, The previous fix was based on ffa_mem_transaction with ffa version 1.0, now optee and Hafnium have updated ffa_mem_transaction to ffa 1.1. But optee-driver in linaro-swg/linux seems to be using ffa version 1.0, which causes incorrect data reading when the driver is doing mem_share to Hafnium. I need to debug my previous code. When will optee-driver synchronize this version change? Regards, Yuye. ------------------------------------------------------------------ 发件人：Jens Wiklander <jens.wiklander(a)linaro.org> 发送时间：2023年6月28日(星期三) 17:54 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：op-tee <op-tee(a)lists.trustedfirmware.org> 主　题：Re: core: fix fragmented memory retrieve Hi Yuye, On Wed, Jun 28, 2023 at 11:50 AM 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> wrote: > > > > > Hi, Jens, > > Sorry for forgetting to revise the PR in time, because my github email changed so I haven't received any comments. > Could you help me reopen the PR since I don't have the right? I will re-fix the problem as requested. > Thanks. > https://github.com/OP-TEE/optee_os/pull/5966 <https://github.com/OP-TEE/optee_os/pull/5966 > I've reopened it. Cheers, Jens

2 years, 11 months

2
1
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE