- OP-TEE - lists.trustedfirmware.org

[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

1 year, 3 months

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. >

1 year, 3 months

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

1 year, 3 months

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

1 year, 3 months

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

1 year, 3 months

3
4
0 0

[PATCH] tee: optee: Fix supplicant based device enumeration

by Sumit Garg

Currently supplicant dependent optee device enumeration only registers devices whenever tee-supplicant is invoked for the first time. But it forgets to remove devices when tee-supplicant daemon stops running and closes its context gracefully. This leads to following splats for fTPM driver during reboot/shutdown: [ 73.466791] tpm tpm0: ftpm_tee_tpm_op_send: SUBMIT_COMMAND invoke error: 0xffff3024 [ 73.474497] ------------[ cut here ]------------ [ 73.479119] WARNING: CPU: 1 PID: 1 at drivers/char/tpm/tpm_ftpm_tee.c:135 ftpm_tee_tpm_op_send+0x200/0x25c <snip> [ 73.539952] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--) [ 73.545946] pc : ftpm_tee_tpm_op_send+0x200/0x25c [ 73.550640] lr : ftpm_tee_tpm_op_send+0x200/0x25c [ 73.555331] sp : ffff80001129baa0 [ 73.558635] x29: ffff80001129baa0 x28: ffff00000646f000 [ 73.563938] x27: ffff8000110f7000 x26: 0000000000000016 [ 73.569241] x25: 0000000000000145 x24: ffff000005395000 [ 73.574544] x23: ffff0000065a7280 x22: ffff00000646f000 [ 73.579847] x21: ffff000006422080 x20: 000000000000000c [ 73.585149] x19: 0000000000000000 x18: 0000000000000000 [ 73.590450] x17: 0000000000000000 x16: 0000000000000000 [ 73.595753] x15: 0000000000000030 x14: ffffffffffffffff [ 73.601055] x13: ffff80001110e838 x12: 00000000000006d2 [ 73.606357] x11: 0000000000000246 x10: ffff800011166838 [ 73.611659] x9 : 00000000fffff000 x8 : ffff80001110e838 [ 73.616962] x7 : ffff800011166838 x6 : 0000000000000000 [ 73.622263] x5 : 0000000000000000 x4 : 0000000000000000 [ 73.627565] x3 : 0000000000000000 x2 : 0000000000000000 [ 73.632867] x1 : 0000000000000000 x0 : ffff0000000e8000 [ 73.638170] Call trace: [ 73.640610] ftpm_tee_tpm_op_send+0x200/0x25c [ 73.644960] tpm_transmit+0xc8/0x33c [ 73.648528] tpm_transmit_cmd+0x30/0xc0 [ 73.652353] tpm2_shutdown+0xa4/0x100 [ 73.656007] tpm_class_shutdown+0x60/0x90 [ 73.660009] device_shutdown+0x138/0x330 [ 73.663926] __do_sys_reboot+0x218/0x2a0 [ 73.667839] __arm64_sys_reboot+0x24/0x30 [ 73.671842] el0_svc_common.constprop.0+0x78/0x1c4 [ 73.676622] do_el0_svc+0x24/0x8c [ 73.679932] el0_svc+0x14/0x20 [ 73.682978] el0_sync_handler+0xb0/0xb4 [ 73.686806] el0_sync+0x180/0x1c0 Fix this properly by removing supplicant dependent devices when the supplicant closes gracefully. While at it use the global system workqueue for OP-TEE bus scanning work rather than our own custom one. Reported-by: Jan Kiszka <jan.kiszka(a)siemens.com> Link: https://github.com/OP-TEE/optee_os/issues/6094 Fixes: 5f178bb71e3a ("optee: enable support for multi-stage bus enumeration") Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org> --- drivers/tee/optee/core.c | 26 +++++++++++--------------- drivers/tee/optee/device.c | 27 ++++++++++++++++++++++++--- drivers/tee/optee/optee_private.h | 7 ++----- 3 files changed, 37 insertions(+), 23 deletions(-) diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c index d01ca47f7bde..e0f2c9cb0073 100644 --- a/drivers/tee/optee/core.c +++ b/drivers/tee/optee/core.c @@ -15,7 +15,6 @@ #include <linux/string.h> #include <linux/tee_drv.h> #include <linux/types.h> -#include <linux/workqueue.h> #include "optee_private.h" int optee_pool_op_alloc_helper(struct tee_shm_pool *pool, struct tee_shm *shm, @@ -84,6 +83,11 @@ static void optee_bus_scan(struct work_struct *work) WARN_ON(optee_enumerate_devices(PTA_CMD_GET_DEVICES_SUPP)); } +static void optee_bus_remove(struct work_struct *work) +{ + optee_unregister_supp_devices(); +} + int optee_open(struct tee_context *ctx, bool cap_memref_null) { struct optee_context_data *ctxdata; @@ -108,16 +112,8 @@ int optee_open(struct tee_context *ctx, bool cap_memref_null) return -EBUSY; } - if (!optee->scan_bus_done) { - INIT_WORK(&optee->scan_bus_work, optee_bus_scan); - optee->scan_bus_wq = create_workqueue("optee_bus_scan"); - if (!optee->scan_bus_wq) { - kfree(ctxdata); - return -ECHILD; - } - queue_work(optee->scan_bus_wq, &optee->scan_bus_work); - optee->scan_bus_done = true; - } + INIT_WORK(&optee->scan_bus_work, optee_bus_scan); + schedule_work(&optee->scan_bus_work); } mutex_init(&ctxdata->mutex); INIT_LIST_HEAD(&ctxdata->sess_list); @@ -159,10 +155,10 @@ void optee_release_supp(struct tee_context *ctx) struct optee *optee = tee_get_drvdata(ctx->teedev); optee_release_helper(ctx, optee_close_session_helper); - if (optee->scan_bus_wq) { - destroy_workqueue(optee->scan_bus_wq); - optee->scan_bus_wq = NULL; - } + + INIT_WORK(&optee->scan_bus_work, optee_bus_remove); + schedule_work(&optee->scan_bus_work); + optee_supp_release(&optee->supp); } diff --git a/drivers/tee/optee/device.c b/drivers/tee/optee/device.c index 64f0e047c23d..88e1c3feb15d 100644 --- a/drivers/tee/optee/device.c +++ b/drivers/tee/optee/device.c @@ -60,9 +60,10 @@ static void optee_release_device(struct device *dev) kfree(optee_device); } -static int optee_register_device(const uuid_t *device_uuid) +static int optee_register_device(const uuid_t *device_uuid, u32 func) { struct tee_client_device *optee_device = NULL; + const char *dev_name_fmt = NULL; int rc; optee_device = kzalloc(sizeof(*optee_device), GFP_KERNEL); @@ -71,7 +72,13 @@ static int optee_register_device(const uuid_t *device_uuid) optee_device->dev.bus = &tee_bus_type; optee_device->dev.release = optee_release_device; - if (dev_set_name(&optee_device->dev, "optee-ta-%pUb", device_uuid)) { + + if (func == PTA_CMD_GET_DEVICES_SUPP) + dev_name_fmt = "optee-ta-supp-%pUb"; + else + dev_name_fmt = "optee-ta-%pUb"; + + if (dev_set_name(&optee_device->dev, dev_name_fmt, device_uuid)) { kfree(optee_device); return -ENOMEM; } @@ -142,7 +149,7 @@ static int __optee_enumerate_devices(u32 func) num_devices = shm_size / sizeof(uuid_t); for (idx = 0; idx < num_devices; idx++) { - rc = optee_register_device(&device_uuid[idx]); + rc = optee_register_device(&device_uuid[idx], func); if (rc) goto out_shm; } @@ -175,3 +182,17 @@ void optee_unregister_devices(void) bus_for_each_dev(&tee_bus_type, NULL, NULL, __optee_unregister_device); } + +static int __optee_unregister_supp_device(struct device *dev, void *data) +{ + if (!strncmp(dev_name(dev), "optee-ta-supp", strlen("optee-ta-supp"))) + device_unregister(dev); + + return 0; +} + +void optee_unregister_supp_devices(void) +{ + bus_for_each_dev(&tee_bus_type, NULL, NULL, + __optee_unregister_supp_device); +} diff --git a/drivers/tee/optee/optee_private.h b/drivers/tee/optee/optee_private.h index 6dcecb83c893..cb5eae6f797d 100644 --- a/drivers/tee/optee/optee_private.h +++ b/drivers/tee/optee/optee_private.h @@ -192,9 +192,7 @@ struct optee_ops { * @supp: supplicant synchronization struct for RPC to supplicant * @pool: shared memory pool * @rpc_param_count: If > 0 number of RPC parameters to make room for - * @scan_bus_done flag if device registation was already done. - * @scan_bus_wq workqueue to scan optee bus and register optee drivers - * @scan_bus_work workq to scan optee bus and register optee drivers + * @scan_bus_work work to scan optee bus and register optee drivers */ struct optee { struct tee_device *supp_teedev; @@ -211,8 +209,6 @@ struct optee { struct optee_supp supp; struct tee_shm_pool *pool; unsigned int rpc_param_count; - bool scan_bus_done; - struct workqueue_struct *scan_bus_wq; struct work_struct scan_bus_work; }; @@ -280,6 +276,7 @@ int optee_cancel_req(struct tee_context *ctx, u32 cancel_id, u32 session); #define PTA_CMD_GET_DEVICES_SUPP 0x1 int optee_enumerate_devices(u32 func); void optee_unregister_devices(void); +void optee_unregister_supp_devices(void); int optee_pool_op_alloc_helper(struct tee_shm_pool *pool, struct tee_shm *shm, size_t size, size_t align, -- 2.34.1

1 year, 3 months

2
1
0 0

[GIT PULL] AMDTEE fix for v6.5

by Jens Wiklander

Hello arm-soc maintainers, Please pull this AMDTEE driver fix to add a return origin field to the struct tee_cmd_load_ta used when loading a Trusted Application into the AMDTEE. This change is backward compatible. Note that this isn't a usual Arm driver update. This targets AMD instead, but is part of the TEE subsystem. 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/amdtee-fix-for-v6.5 for you to fetch changes up to 436eeae0411acdfc54521ddea80ee76d4ae8a7ea: tee: amdtee: Add return_origin to 'struct tee_cmd_load_ta' (2023-05-15 08:29:52 +0200) ---------------------------------------------------------------- AMDTEE add return origin to load TA command ---------------------------------------------------------------- Rijo Thomas (1): tee: amdtee: Add return_origin to 'struct tee_cmd_load_ta' drivers/tee/amdtee/amdtee_if.h | 10 ++++++---- drivers/tee/amdtee/call.c | 30 +++++++++++++++++------------- 2 files changed, 23 insertions(+), 17 deletions(-)

1 year, 3 months

2
3
0 0

optee_benchmark pmccfiltr_el0

by 梅建强(禹夜)

Hi, Olivier, That makes it clearer to me. Thanks a lot. Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年5月30日(星期二) 21:07 收件人：Jens Wiklander <jens.wiklander(a)linaro.org>; 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：op-tee <op-tee(a)lists.trustedfirmware.org>; hafnium <hafnium(a)lists.trustedfirmware.org>; 黄明(连一) <hm281385(a)alibaba-inc.com> 主　题：Re: optee_benchmark pmccfiltr_el0 Hi Yuye, In general the consensus is that PMU cycle and event counting in EL3 & secure world has to be disabled. I gather this is to avoid probing crypto algorithms timings, or leverage cache-based timing side channels (e.g. spectre). See Arm ARM D11.5.3 Prohibiting event and cycle counting Cycle and event counting is disabled by: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/include/ar… <https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/include/ar… > See also https://trustedfirmware-a.readthedocs.io/en/latest/process/security-hardeni… <https://trustedfirmware-a.readthedocs.io/en/latest/process/security-hardeni… > Note there are various knobs depending on implemented architecture extensions FEAT_PMUv3 / FEAT_PMUv3pX / FEAT_Debugv8p2 You could try to permit cycle counting in the secure world for the sake of a one shot experiment, but note that this has never been tried, and this should probably not be productized as things stand. Regards, Olivier. From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 30 May 2023 10:38 To: Jens Wiklander <jens.wiklander(a)linaro.org>; Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: op-tee <op-tee(a)lists.trustedfirmware.org>; hafnium <hafnium(a)lists.trustedfirmware.org>; 黄明(连一) <hm281385(a)alibaba-inc.com> Subject: optee_benchmark pmccfiltr_el0 Hi, It is confirmed that the problem is related to the pmu register configuration and that pmccntr_el0 can be read at any exception level. Regards, Yuye. ------------------------------------------------------------------ 发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 发送时间：2023年5月26日(星期五) 16:59 收件人：Jens Wiklander <jens.wiklander(a)linaro.org>; Olivier Deprez <olivier.deprez(a)arm.com> 抄　送：op-tee <op-tee(a)lists.trustedfirmware.org>; hafnium <hafnium(a)lists.trustedfirmware.org>; 黄明(连一) <hm281385(a)alibaba-inc.com> 主　题：optee_benchmark pmccfiltr_el0 Hi, Jens, Olivier, In case of that optee runs at sel1 and hafnium runs at sel2, we want to test benchmark by executing the following command at optee_benchmark path: ./out/benchmark ../optee_examples/out/ca/optee_example_hello_world After entering into the benchmark pta, the bm_timestamp function attempts to read the pmccfiltr_el0 register. In cold boot, the following code will be executed during hafnium initialization: vm->arch.trapped_features |= HF_FEATURE_PERFMON; This will prevent the secondary vm from accessing the performance counter registers. We remove the code, the bm_timestamp function can read pmccfiltr_el0 without trapping into hafnium. But the value of pmccfiltr_el0 remains unchanged and cannot be counted. We tried to read the register in hafnium and found that there was no change either. In contrast, in the normal world, pmccfiltr_el0 counts normally. Is it related to the pmu register configuration or does sel1 not support the pmccfiltr_el0 count at present? Thanks for the support. Regards, Yuye.

1 year, 4 months

1
0
0 0

[RFC PATCH 0/4] introduction of a remoteproc tee to load signed firmware images

by Arnaud Pouliquen

This RFC proposes an implementation of a remoteproc tee driver to communicate with a TEE trusted application in charge of authenticating and loading remoteproc firmware image in an Arm secure context. The services implemented are the same as those offered by the Linux remoteproc framework: - load of a signed firmware - start/stop of a coprocessor - get the resource table The OP-TEE code in charge of providing the service in a trusted application is proposed for upstream here: https://github.com/OP-TEE/optee_os/pull/6027 For more details on the implementation a presentation is available here: https://resources.linaro.org/en/resource/6c5bGvZwUAjX56fvxthxds Arnaud Pouliquen (4): tee: Re-enable vmalloc page support for shared memory remoteproc: Add TEE support dt-bindings: remoteproc: add compatibility for TEE support remoteproc: stm32: Add support of an OP-TEE TA to load the firmware .../bindings/remoteproc/st,stm32-rproc.yaml | 33 +- drivers/remoteproc/Kconfig | 9 + drivers/remoteproc/Makefile | 1 + drivers/remoteproc/stm32_rproc.c | 234 +++++++++-- drivers/remoteproc/tee_remoteproc.c | 397 ++++++++++++++++++ drivers/tee/tee_shm.c | 24 +- include/linux/tee_remoteproc.h | 101 +++++ 7 files changed, 753 insertions(+), 46 deletions(-) create mode 100644 drivers/remoteproc/tee_remoteproc.c create mode 100644 include/linux/tee_remoteproc.h -- 2.25.1

1 year, 4 months

5
14
0 0

optee_benchmark pmccfiltr_el0

by 梅建强(禹夜)

Hi, It is confirmed that the problem is related to the pmu register configuration and that pmccntr_el0 can be read at any exception level. Regards, Yuye. ------------------------------------------------------------------ 发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 发送时间：2023年5月26日(星期五) 16:59 收件人：Jens Wiklander <jens.wiklander(a)linaro.org>; Olivier Deprez <olivier.deprez(a)arm.com> 抄　送：op-tee <op-tee(a)lists.trustedfirmware.org>; hafnium <hafnium(a)lists.trustedfirmware.org>; 黄明(连一) <hm281385(a)alibaba-inc.com> 主　题：optee_benchmark pmccfiltr_el0 Hi, Jens, Olivier, In case of that optee runs at sel1 and hafnium runs at sel2, we want to test benchmark by executing the following command at optee_benchmark path: ./out/benchmark ../optee_examples/out/ca/optee_example_hello_world After entering into the benchmark pta, the bm_timestamp function attempts to read the pmccfiltr_el0 register. In cold boot, the following code will be executed during hafnium initialization: vm->arch.trapped_features |= HF_FEATURE_PERFMON; This will prevent the secondary vm from accessing the performance counter registers. We remove the code, the bm_timestamp function can read pmccfiltr_el0 without trapping into hafnium. But the value of pmccfiltr_el0 remains unchanged and cannot be counted. We tried to read the register in hafnium and found that there was no change either. In contrast, in the normal world, pmccfiltr_el0 counts normally. Is it related to the pmu register configuration or does sel1 not support the pmccfiltr_el0 count at present? Thanks for the support. Regards, Yuye.

1 year, 4 months

2
1
0 0

2024

2023

2022

2021

2020

OP-TEE