- OP-TEE - lists.trustedfirmware.org

optee_benchmark found optee_os function vm_set_ctx() spent much time

by haiyuan.ghy＠alibaba-inc.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

1 year, 9 months

3
8
0 0

core: fix fragmented memory retrieve

by 梅建强(禹夜)

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 > Regards, Yuye.

1 year, 9 months

2
1
0 0

[RFC PATCH 1/1] tests/avocado: Introduce avocado tests for aarch64 S-EL2 booting

by shiju.jose＠huawei.com

From: Shiju Jose <shiju.jose(a)huawei.com> Add avocado tests for aarch64 S-EL2, include booting and run xtest on linux terminal. The prebuilt S-EL2 images are corresponding to the https://github.com/jenswi-linaro/manifest.git \ -m qemu_v8.xml -b qemu_sel2 How to run ========== "make check-avocado" in qemu/build or with QEMU_CI=1 and QEMU_CI_AVOCADO_TESTING=1 "amd64-fedora-container", "build-cfi-aarch64" and "avocado-cfi-aarch64" on gitlab for qemu Question: Presently tested with the prebuilt images temporarily in /tests/data/sel2-boot-images/prebuilt-sel2-images.zip Can the prebuilt images for SEL2 available in the OP-TEE/TF-A/similar release? Note1: The pre-built S-EL2 images used are few months old as there are some issue found in xtest with the images build from the recent Linaro SEL2 code. Note2: On gitlab CI, there is an outstanding issue found in booting linux, after starting network OK. Signed-off-by: Shiju Jose <shiju.jose(a)huawei.com> --- tests/avocado/machine_aarch64_virt.py | 63 ++++++++++++++++++ .../sel2-boot-images/prebuilt-sel2-images.zip | Bin 0 -> 23151996 bytes 2 files changed, 63 insertions(+) create mode 100644 tests/data/sel2-boot-images/prebuilt-sel2-images.zip diff --git a/tests/avocado/machine_aarch64_virt.py b/tests/avocado/machine_aarch64_virt.py index a90dc6ff4b..039673fd40 100644 --- a/tests/avocado/machine_aarch64_virt.py +++ b/tests/avocado/machine_aarch64_virt.py @@ -11,13 +11,16 @@ import time import os import logging +import shutil from avocado_qemu import QemuSystemTest from avocado_qemu import wait_for_console_pattern from avocado_qemu import exec_command from avocado_qemu import BUILD_DIR +from avocado_qemu import is_readable_executable_file from avocado.utils import process from avocado.utils.path import find_command +from avocado.utils import archive class Aarch64VirtMachine(QemuSystemTest): KERNEL_COMMON_COMMAND_LINE = 'printk.time=0 ' @@ -144,3 +147,63 @@ def test_aarch64_virt_gicv2(self): :avocado: tags=cpu:max """ self.common_aarch64_virt("virt,gic-version=2") + + def copy_sel2_prebuilt_images(self): + """extract the prebuilt S-EL2 binaries to the test directory. """ + + relative_path = "./tests/data/sel2-boot-images/prebuilt-sel2-images.zip" + prebuilt_bin_path = os.path.join(BUILD_DIR, relative_path) + target_dir = os.path.join(BUILD_DIR) + + self.assertTrue(os.path.exists(prebuilt_bin_path)) + self.assertTrue(os.path.exists(target_dir)) + archive.extract(prebuilt_bin_path, target_dir) + + timeout = 1000 + def test_aarch64_sel2_boot(self): + """ + :avocado: tags=arch:aarch64 + :avocado: tags=machine:secure + :avocado: tags=machine:virt + :avocado: tags=cpu:max + """ + + self.copy_sel2_prebuilt_images() + self.vm.set_console() + kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE + + 'console=ttyAMA0,38400 keep_bootcon root=/dev/vda2 nokaslr') + + self.vm.add_args("-cpu", "max,sme=off,pauth-impdef=on") + self.vm.add_args("-machine", + "virt,secure=on," + "virtualization=on," + "mte=on," + "gic-version=3") + self.vm.add_args("-d", "unimp") + self.vm.add_args("-semihosting-config", "enable=on,target=native") + self.vm.add_args("-smp", "2", "-m", "1024") + self.vm.add_args('-bios', 'bl1.bin') + self.vm.add_args('-initrd', 'rootfs.cpio.gz') + self.vm.add_args('-kernel', 'Image') + self.vm.add_args('-machine', 'acpi=off') + self.vm.add_args('-append', kernel_command_line) + self.vm.add_args('-object', 'rng-random,filename=/dev/urandom,id=rng0') + self.vm.add_args('-device', 'virtio-rng-pci,rng=rng0,max-bytes=1024,period=1000') + self.vm.launch() + self.wait_for_console_pattern('Welcome to Buildroot') + time.sleep(0.1) + exec_command(self, 'root') + time.sleep(0.1) + + def test_aarch64_sel2_xtest(self): + """ + :avocado: tags=arch:aarch64 + :avocado: tags=machine:secure + :avocado: tags=machine:virt + :avocado: tags=cpu:max + """ + self.test_aarch64_sel2_boot() + exec_command(self, 'xtest') + time.sleep(0.1) + self.wait_for_console_pattern('subtests of which 0 failed') + time.sleep(0.1) diff --git a/tests/data/sel2-boot-images/prebuilt-sel2-images.zip b/tests/data/sel2-boot-images/prebuilt-sel2-images.zip new file mode 100644 index 0000000000..13c5e1e4cc Binary files /dev/null and b/tests/data/sel2-boot-images/prebuilt-sel2-images.zip differ -- 2.25.1

1 year, 9 months

1
0
0 0

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

1 year, 10 months

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,

1 year, 10 months

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

1 year, 10 months

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

1 year, 10 months

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.

1 year, 10 months

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

1 year, 10 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, 10 months

1
0
0 0

2025

2024

2023

2022

2021

2020

OP-TEE