- OP-TEE - lists.trustedfirmware.org

Linaro OP-TEE Contribution, LOC, monthly meeting June 27

by Jens Wiklander

Hi, On Tuesday, June 27 it's time for another LOC monthly meeting. For time and connection details see the calendar at https://www.trustedfirmware.org/meetings/ I'd like to discuss how MbedTLS is used in OP-TEE. While trying to update to MbedTLS 3.4 on the 4.x WIP branch [1] we have run into yet another issue with the CRT parameters used in the RSA implementation. See [2] for more details on the CRT problem. [1] https://github.com/jenswi-linaro/optee_os/tree/wip_4_0_0 [2] https://github.com/jenswi-linaro/optee_os/pull/9 any other topics? Thanks, Jens

2 years

1
0
0 0

PKCS11 TA: MR https://github.com/OP-TEE/optee_os/pull/5166

by dourlent cédric

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,

2 years

3
2
0 0

[GIT PULL] Use kmemdup() in OP-TEE driver for v6.5

by Jens Wiklander

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(-)

2 years

1
0
0 0

[PATCH v2] tee: optee: Use kmemdup() to replace kmalloc + memcpy

by Jiapeng Chong

Use kmemdup rather than duplicating its implementation. ./drivers/tee/optee/smc_abi.c:1542:12-19: WARNING opportunity for kmemdup. Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5480 Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> --- Changes in v2: -Add one commit message. drivers/tee/optee/smc_abi.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c index 3861ae06d902..d5b28fd35d66 100644 --- a/drivers/tee/optee/smc_abi.c +++ b/drivers/tee/optee/smc_abi.c @@ -1541,12 +1541,11 @@ static int optee_load_fw(struct platform_device *pdev, * This uses the GFP_DMA flag to ensure we are allocated memory in the * 32-bit space since TF-A cannot map memory beyond the 32-bit boundary. */ - data_buf = kmalloc(fw->size, GFP_KERNEL | GFP_DMA); + data_buf = kmemdup(fw->data, fw->size, GFP_KERNEL | GFP_DMA); if (!data_buf) { rc = -ENOMEM; goto fw_err; } - memcpy(data_buf, fw->data, fw->size); data_pa = virt_to_phys(data_buf); reg_pair_from_64(&data_pa_high, &data_pa_low, data_pa); reg_pair_from_64(&data_size_high, &data_size_low, data_size); -- 2.20.1.7.g153144c

2 years

3
2
0 0

reference keymint & gatekeeper TAs

by Nagendra Modadugu

I'm writing to get further information regarding the support roadmap for OP-TEE based TA's - specifically keymint and gatekeeper. The implementations I could find are here: https://github.com/linaro-swg/kmgk, and was wondering whether these are supported? Please respond off list if you find that would be more appropriate for discussion. thanks.

2 years

2
1
0 0

[PATCH v2 0/4] rpmb subsystem, uapi and virtio-rpmb driver

by Shyam Saini

Hi Alex, [ Resending, Sorry for the noise ] Are you still working on it or planning to resubmit it ? [1] The current optee tee kernel driver implementation doesn't work when IMA is used with optee implemented ftpm. The ftpm has dependency on tee-supplicant which comes once the user space is up and running and IMA attestation happens at boot time and it requires to extend ftpm PCRs. But IMA can't use PCRs if ftpm use secure emmc RPMB partition. As optee can only access RPMB via tee-supplicant(user space). So, there should be a fast path to allow optee os to access the RPMB parititon without waiting for user-space tee supplicant. To achieve this fast path linux optee driver and mmc driver needs some work and finally it will need RPMB driver which you posted. Please let me know what's your plan on this. [1] https://optee.readthedocs.io/en/latest/architecture/secure_storage.html Best Regards, Shyam

2 years

5
7
0 0

Re: FOLL_LONGTERM vs FOLL_EPHEMERAL Re: [PATCH] tee: add FOLL_LONGTERM for CMA case when alloc shm

by Sumit Garg

On Tue, 13 Jun 2023 at 11:00, Xiaoming Ding (丁晓明) <Xiaoming.Ding(a)mediatek.com> wrote: > > So do we have a conclution about this patch? or need more time to > study the possible risks Please avoid top posting. As already discussed here [1], RLIMIT_MEMLOCK checks have to be implemented if we switch to FOLL_LONGTERM. [1] https://lists.trustedfirmware.org/archives/list/op-tee@lists.trustedfirmwar… -Sumit > > On Tue, 2023-05-23 at 08:25 +0100, Lorenzo Stoakes wrote: > > External email : Please do not click links or open attachments until > > you have verified the sender or the content. > > > > > > On Mon, May 22, 2023 at 06:54:29PM -0700, John Hubbard wrote: > > > On 5/18/23 06:56, David Hildenbrand wrote: > > > > On 18.05.23 08:08, Sumit Garg wrote: > > > > > On Thu, 18 May 2023 at 09:51, Christoph Hellwig < > > > > > hch(a)infradead.org> wrote: > > > > > > > > > > > > On Wed, May 17, 2023 at 08:23:33PM +0200, David Hildenbrand > > > > > > wrote: > > > > > > > In general: if user space controls it -> possibly forever > > > > > > > -> long-term. Even > > > > > > > if in most cases it's a short delay: there is no trusting > > > > > > > on user space. > > > > > > > > > > > > > > For example, iouring fixed buffers keep pages pinned until > > > > > > > user space > > > > > > > decides to unregistered the buffers -> long-term. > > > > > > > > > > > > > > Short-term is, for example, something like O_DIRECT where > > > > > > > we pin -> DMA -> > > > > > > > unpin in essentially one operation. > > > > > > > > > > > > Btw, one thing that's been on my mind is that I think we got > > > > > > the > > > > > > polarity on FOLL_LONGTERM wrong. Instead of opting into the > > > > > > long term > > > > > > behavior it really should be the default, with a > > > > > > FOLL_EPHEMERAL flag > > > > > > to opt out of it. And every users of this flag is required > > > > > > to have > > > > > > a comment explaining the life time rules for the pin.. > > > > I couldn't agree more, based on my recent forays into GUP the > > interface > > continues to strike me as odd:- > > > > - FOLL_GET is a wing and a prayer that nothing that > > [folio|page]_maybe_dma_pinned() prevents happens in the brief > > period the > > page is pinned/manipulated. So agree completely with David's > > concept of > > unexporting that and perhaps carefully considering our use of > > it. Obviously the comments around functions like gup_remote() make > > clear > > that 'this page not be what you think it is' but I wonder whether > > many > > callers of GUP _truly_ take that on board. > > > > - FOLL_LONGTERM is entirely optional for PUP and you can just go > > ahead and > > fragment page blocks to your heart's content. Of course this would > > be an > > abuse, but abuses happen. > > > > - With the recent change to PUP/FOLL_LONGTERM disallowing dirty > > tracked > > file-backed mappings we're now really relying on this flag > > indicating a > > _long term_ pin semantically. By defaulting to this being switched > > on, we > > avoid cases of callers who might end up treating the won't > > reclaim/etc. aspect of PUP as all they care about while ignoring > > the > > MIGRATE_MOVABLE aspect. > > > > > > > > I see maybe 10 or 20 call sites today. So it is definitely feasible > > > to add > > > documentation at each, explaining the why it wants a long term pin. > > > > > > > Yeah, my efforts at e.g. dropping vmas has been eye-opening in > > actually > > quite how often a refactoring like this often ends up being more > > straightforward than you might imagine. > > > > > > > > > > > > It does look like a better approach to me given the very nature > > > > > of > > > > > user space pages. > > > > > > > > Yeah, there is a lot of historical baggage. For example, FOLL_GET > > > > should be inaccessible to kernel modules completely at one point, > > > > to be only used by selected core-mm pieces. > > > > > > Yes. When I first mass-converted call sites from gup to pup, I just > > > preserved FOLL_GET behavior in order to keep from changing too much > > > at > > > once. But I agree that that it would be nice to make FOLL_GET an > > > mm internal-only flag like FOLL_PIN. > > > > Very glad you did that work! And totally understandable as to you > > being > > conservative with that, but I think we're at a point where there's > > more > > acceptance of incremental improvements to GUP as a whole. > > > > I have another patch series saved up for _yet more_ changes on this. > > But > > mindful of churn I am trying to space them out... until Jason nudges > > me of > > course :) > > > > > > > > > > > > > Maybe we should even disallow passing in FOLL_LONGTERM as a flag > > > > and only provide functions like pin_user_pages() vs. > > > > pin_user_pages_longterm(). Then, discussions about conditional > > > > flag-setting are no more :) > > > > > > > > ... or even use pin_user_pages_shortterm() vs. pin_user_pages() > > > > ... to make the default be longterm. > > > > > > > > > > Yes, it is true that having most gup flags be internal to mm does > > > tend > > > to avoid some bugs. But it's also a lot of churn. I'm still on the > > > fence > > > as to whether it's really a good move to do this for FOLL_LONGTERM > > > or > > > not. But it's really easy to push me off of fences. :) > > > > *nudge* ;) > > > > > > > > thanks, > > > -- > > > John Hubbard > > > NVIDIA > > > > > > > Looking at non-fast, non-FOLL_LONGTERM PUP callers (forgive me if I > > missed any):- > > > > - pin_user_pages_remote() in process_vm_rw_single_vec() for the > > process_vm_access functionality. > > > > - pin_user_pages_remote() in user_event_enabler_write() in > > kernel/trace/trace_events_user.c. > > > > - pin_user_pages_unlocked() in ivtv_udma_setup() in > > drivers/media/pci/ivtv/ivtv-udma.c and ivtv_yuv_prep_user_dma() in > > ivtv-yuv.c. > > > > And none that actually directly invoke PUP without FOLL_LOGNTERM... > > That > > suggests that we could simply disallow non-FOLL_LONGTERM non-fast PUP > > calls > > altogether and move to pin_user_pages_longterm() [I'm happy to write > > a > > patch series doing this]. > > > > The ivtv callers look like they really actually want FOLL_LONGTERM > > unless > > I'm missing something so we should probably change that too? > > > > I haven't surveyed the fast versions, but I think defaulting to > > FOLL_LONGTERM on them also makes sense. >

2 years

1
0
0 0

[PATCH] tee: optee: Use kmemdup() to replace kmalloc + memcpy

by Jiapeng Chong

./drivers/tee/optee/smc_abi.c:1542:12-19: WARNING opportunity for kmemdup. Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5480 Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> --- drivers/tee/optee/smc_abi.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c index 3861ae06d902..d5b28fd35d66 100644 --- a/drivers/tee/optee/smc_abi.c +++ b/drivers/tee/optee/smc_abi.c @@ -1541,12 +1541,11 @@ static int optee_load_fw(struct platform_device *pdev, * This uses the GFP_DMA flag to ensure we are allocated memory in the * 32-bit space since TF-A cannot map memory beyond the 32-bit boundary. */ - data_buf = kmalloc(fw->size, GFP_KERNEL | GFP_DMA); + data_buf = kmemdup(fw->data, fw->size, GFP_KERNEL | GFP_DMA); if (!data_buf) { rc = -ENOMEM; goto fw_err; } - memcpy(data_buf, fw->data, fw->size); data_pa = virt_to_phys(data_buf); reg_pair_from_64(&data_pa_high, &data_pa_low, data_pa); reg_pair_from_64(&data_size_high, &data_size_low, data_size); -- 2.20.1.7.g153144c

2 years

2
1
0 0

[PATCH v5 0/3] 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: 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 (3): efi: expose efivar generic ops register function efi: Add EFI_ACCESS_DENIED status code efi: Add tee-based EFI variable driver drivers/firmware/efi/Kconfig | 15 + drivers/firmware/efi/Makefile | 1 + drivers/firmware/efi/efi.c | 12 + drivers/firmware/efi/stmm/mm_communication.h | 236 +++++++ drivers/firmware/efi/stmm/tee_stmm_efi.c | 638 +++++++++++++++++++ include/linux/efi.h | 4 + 6 files changed, 906 insertions(+) create mode 100644 drivers/firmware/efi/stmm/mm_communication.h create mode 100644 drivers/firmware/efi/stmm/tee_stmm_efi.c -- 2.30.2

2 years

6
33
0 0

[PATCH v5 1/2] dt-bindings: arm: optee: add interrupt controller properties

by Etienne Carriere

Adds an optional interrupt controller property to optee firmware node in the DT bindings. Optee driver may embeds an irqchip exposing OP-TEE interrupt events notified by the TEE world. Optee registers up to 1 interrupt controller and identifies each line with a line number from 0 to UINT16_MAX. The identifiers and meaning of the interrupt line number are specific to the platform and shall be found in the OP-TEE platform documentation. In the example shown in optee DT binding documentation, the platform SCMI device controlled by Linux scmi driver uses optee interrupt irq 5 as signal to trigger processing of an asynchronous incoming SCMI message in the scope of a CPU DVFS control. A platform can have several SCMI channels driven this way. Optee irqs also permit small embedded devices to share e.g. a gpio expander, a group of wakeup sources, etc... between OP-TEE world (for sensitive services) and Linux world (for non-sensitive services). The physical controller is driven from the TEE which exposes some controls to Linux kernel. Cc: Jens Wiklander <jens.wiklander(a)linaro.org> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt(a)linaro.org> Cc: Marc Zyngier <maz(a)kernel.org> Cc: Rob Herring <robh+dt(a)kernel.org> Cc: Sumit Garg <sumit.garg(a)linaro.org> Co-developed-by: Pascal Paillet <p.paillet(a)foss.st.com> Signed-off-by: Pascal Paillet <p.paillet(a)foss.st.com> Signed-off-by: Etienne Carriere <etienne.carriere(a)linaro.org> --- Changes since v4: - Removed empty line between Cc: tags and S-o-b tags. No changes since v3 Changes since v2: - Added a sentence on optee irq line number values and meaning, in DT binding doc and commit message. - Updated example in DT binding doc from comment, fixed misplaced interrupt-parent property and removed gic and sram shm nodes. Changes since v1: - Added a description to #interrupt-cells property. - Changed of example. Linux wakeup event was subject to discussion and i don't know much about input events in Linux. So move to SCMI. In the example, an SCMI server in OP-TEE world raises optee irq 5 so that Linux scmi optee channel &scmi_cpu_dvfs pushed in the incoming SCMI message in the scmi device for liekly later processing in threaded context. The example includes all parties: optee, scmi, sram, gic. - Obviously rephrased the commit message. --- .../arm/firmware/linaro,optee-tz.yaml | 38 +++++++++++++++++++ 1 file changed, 38 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml index 5d033570b57b..9d9a797a6b2f 100644 --- a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml +++ b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml @@ -41,6 +41,16 @@ properties: HVC #0, register assignments register assignments are specified in drivers/tee/optee/optee_smc.h + interrupt-controller: true + + "#interrupt-cells": + const: 1 + description: | + OP-TEE exposes irq for irp chip controllers from OP-TEE world. Each + irq is assigned a single line number identifier used as first argument. + Line number identifiers and their meaning shall be found in the OP-TEE + firmware platform documentation. + required: - compatible - method @@ -65,3 +75,31 @@ examples: method = "hvc"; }; }; + + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + firmware { + optee: optee { + compatible = "linaro,optee-tz"; + method = "smc"; + interrupt-parent = <&gic>; + interrupts = <GIC_SPI 187 IRQ_TYPE_EDGE_RISING>; + interrupt-controller; + #interrupt-cells = <1>; + }; + + scmi { + compatible = "linaro,scmi-optee"; + linaro,optee-channel-id = <0>; + shmem = <&scmi_shm_tx>, <&scmi_shm_rx>; + interrupts-extended = <&optee 5>; + interrupt-names = "a2p"; + #address-cells = <1>; + #size-cells = <0>; + + scmi_cpu_dvfs: protocol@13 { + reg = <0x13>; + #clock-cells = <1>; + }; + }; + }; -- 2.25.1

2 years

3
4
0 0

2025

2024

2023

2022

2021

2020

OP-TEE