mk: make the dev kit configuration available while Android.mk is parsed - #12
Closed
andrew2311 wants to merge 1144 commits into
Closed
mk: make the dev kit configuration available while Android.mk is parsed#12andrew2311 wants to merge 1144 commits into
andrew2311 wants to merge 1144 commits into
Conversation
close_persistent_db() is a no-op stub that never frees the db_main and db_objs structures allocated by init_persistent_db(). In normal TA operation this is harmless since the TEE framework reclaims all TA memory on unload, which is likely why it was left unimplemented. However, the leak becomes visible when running the TA in a host-based test environment (e.g. with AddressSanitizer) where the TEE memory reclamation does not occur. ASan reports 264 leaked allocations totalling ~24 KiB per TA lifecycle. Implement close_persistent_db() to free token->db_main and token->db_objs and NULL the pointers. Add a NULL check on the token argument for robustness. Fixes: c84ccd0 ("ta: pkcs11: persistent database for the pkcs11 tokens") Signed-off-by: Georges Savoundararadj <savoundg@amazon.com> Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>
Add support for lemans SoC with platform support tested on lemans EVK platform also known as Qualcomm Dragonwing IQ-9075. More information regarding this platform can be found here [1]. [1] https://www.qualcomm.com/internet-of-things/products/iq9-series/iq-9075 Reviewed-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Add PLATFORM=qcom-lemans build. Acked-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Harden the checks for FF-A memory transaction operations. Check that internal parts are well aligned and that we can handle fragmented transactions. Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org> Acked-by: Jerome Forissier <jerome.forissier@arm.com>
Add support to retrieve a fragmented memory transaction via an SPMC at S-EL2. Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org> Acked-by: Jerome Forissier <jerome.forissier@arm.com>
EdDsa key weren't enabled to be re-used in the same session in the load_tee_key function, forcing the client to close the session and open it again whenever the same operation should have been done multiple times. Closes: OP-TEE#7686 Fixes: 03e0743 ("ta: pkcs11: Add Ed25519 support") Signed-off-by: Christian Zoia <czoia@amazon.com> Reviewed-by: Etienne Carriere <etienne.carriere@st.com>
Add OP-TEE support for the MT7986 SoC. Signed-off-by: guan-gm.lin <guan-gm.lin@mediatek.com> Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
Add OP-TEE support for the MT7981 SoC. Signed-off-by: guan-gm.lin <guan-gm.lin@mediatek.com> Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
Add OP-TEE support for the MT7987 SoC. Signed-off-by: guan-gm.lin <guan-gm.lin@mediatek.com> Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
The early console is very useful for debugging. Alas, a misconfigured early console seems to be halting/panicking OP-TEE OS. Better have something always work possibly without console output (e.g. if no FDT is passed to OP-TEE OS) than crashing without information. The user can still enable the console if they want to for debugging sessions. This fixes OP-TEE OS crashing on RK3399 Puma which uses UART0 instead of default UART2. I've tested on PX30 and RK3588 by specifying a UART controller different from the one that can be used by the device. Acked-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Fix typo for python command line $(q)scripts/gen_tee_bin.py => $(q)$(PYTHON3) scripts/gen_tee_bin.py Signed-off-by: guan-gm.lin <guan-gm.lin@mediatek.com> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Similarly to what's been done to RK3399 in commit 3ab148c ("plat-rockchip: rk3399: set CFG_CRYPTO_WITH_CE ?= y"), we can enable the Arm Cryptography Extensions by default for PX30 as Rockchip claims they are supported in the datasheet[1]. Tested with: xtest --aes-perf -m XTS -s 1000000 -n 1000 Before: min=88574.2us max=91273us mean=88942.8us stddev=234.498us (cv 0.26365%) (10.7223MiB/s) After: min=3297.58us max=3655.75us mean=3464.66us stddev=59.7159us (cv 1.72357%) (275.258MiB/s) Link: https://opensource.rock-chips.com/images/8/87/Rockchip_PX30_Datasheet_V1.4-20191227.pdf [1] Acked-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Edit MAINTAINERS to add myself as maintainer for MediaTek support. Signed-off-by: guan-gm.lin <guan-gm.lin@mediatek.com>
Mailbox driver waits for 10ms to get a response from TIFS, before flagging the transaction a failure. 10ms seems to be right at the edge, since unrelated updates to other components in the boot chain are causing the actual wait time to increase. Therefore increase the timeout to 1000ms. 1000ms is chosen to keep uniformity with the mailbox driver in TF-A. Signed-off-by: Suhaas Joshi <s-joshi@ti.com> Reviewed-by: Andrew Davis <afd@ti.com>
I am changing employer. Change my email address to a dedicated personal one to keep an eye on the stm32 changes for now. Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com> Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
Fixes two mixups of bits and bytes in caam_key_init that roughly cancel each other out. Both sec_size and the result from caam_key_serialized_size are values in bytes, so the key sizes in bits need to be converted. For plain text keys this makes no difference to the result since they cancel each other out exactly. For the default key type of BLACK_CCM the blob overhead is now correctly counted as bytes instead of bits which decreases the headroom, but since the default config of 4576 was calculated correctly, the assert still shouldn't fail. Fixes: 1495f6c ("drivers: caam: add CAAM key driver") Signed-off-by: Martin Nyhus <martin@nyhus.dev> Acked-by: Sahil Malhotra <sahil.malhotra@nxp.com>
Adjusts the caam key serialization code to account for keys where sec_size < buf.length. When that is the case the serialization can only touch the first sec_size bytes since the rest are invalid, and the serialized length is thus sec_size. If the default key type has been changed to plain this can happen during RSA keygen if the d parameter ends up shorter than the key size in bytes. In that case the valid bytes are at the front of the buffer and do_gen_keypair accounts for this by setting sec_size correctly, and caam_key_serialize_to_bn is called with an inkey in the sec_size < buf.length state. This ended up creating corrupt keys for roughly 1% of keygens, and was caught by various RSA tests in optee_test. Fixes: 1495f6c ("drivers: caam: add CAAM key driver") Signed-off-by: Martin Nyhus <martin@nyhus.dev> Acked-by: Sahil Malhotra <sahil.malhotra@nxp.com>
When using CAAM to generate an RSA key the CPU caching of the DMA buffers need to be controlled to ensure the correct visibility for both devices. For the n parameter the wrong address was used when invalidating the CPU cache after the DMA operation, resulting in <key length> bytes of the stack being invalidated (without flushing to memory) instead of the buffer. The first potential consequence of this is that any parts of the n buffer that were cached during the key generation won't get read from RAM, resulting in a corrupt key. This is unlikely since the n buffer was correctly flushed immediately before starting the CAAM operation. To reliably reproduce this, a read that should normally be harmless can be inserted immediately before caam_jr_enqueue: ((volatile uint8_t *)genkey.n.data)[0]; The second effect of this bug is that parts of the do_gen_keypair stack frame will have its cache lines invalidated (again without write back to memory). With 4096 bit keys and a compiler that produces the right stack layout this affects callee saved registers, the return pointer and potentially a stack canary. I have not been able to see the effects of this on my iMX8MQ test device. Fixes: ccbccee ("drivers: caam: add CAAM key support for RSA") Signed-off-by: Martin Nyhus <martin@nyhus.dev> Acked-by: Sahil Malhotra <sahil.malhotra@nxp.com>
Add support for the AMD Application Security Unit (ASU), the on-chip Hardware Security Module (HSM) for Versal Gen 2. The ASU manages all device-level security services for user applications, extending beyond accelerator-centric tasks. Its firmware also exposes several software-based cryptographic primitives, including: - Key transfer - RSA authentication (multiple padding schemes) - HMAC - Key Derivation Function (KDF) - Key wrap / unwrap Co-developed-by: Harsh Jain <h.jain@amd.com> Signed-off-by: Harsh Jain <h.jain@amd.com> Signed-off-by: Akshay Belsare <akshay.belsare@amd.com> Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
Add support for following Hash algorithms SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512 Signed-off-by: Harsh Jain <h.jain@amd.com> Signed-off-by: Akshay Belsare <akshay.belsare@amd.com> Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
New page table pages must always start cleared. On some platforms (e.g., QEMU) RAM happens to be zeroed at reset, but on real hardware (FPGA/SoC DDR) may not be the case. Without this memset, stale contents can make core_mmu_map_region() see non-zero old_attr and panic with "Page is already mapped" when CFG_DYN_CONFIG is enabled. Signed-off-by: Yu-Chien Peter Lin <peter.lin@sifive.com> Reviewed-by: Alvin Chang <alvinga@andestech.com> Reviewed-by: Marouene Boubakri <marouene.boubakri@nxp.com>
The i.MX6DP/QP SoCs have a 2nd memory controller as well which must be configured. This commit covers only the i.MX6QP because there is no i.MX6DP OP-TEE platform yet. Reviewed-by: Sahil Malhotra <sahil.malhotra@nxp.com> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Dumping region0 is interesting too since it may have a insecure sp configuration applied by the previous running firmware. Reviewed-by: Sahil Malhotra <sahil.malhotra@nxp.com> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Add a helper which verifies that region0 is only accessible by the secure world. Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Reviewed-by: Sahil Malhotra <sahil.malhotra@nxp.com> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
There are platforms where memory aliasing can't be prevented, e.g. the i.MX8M. If the previous running firmware configured region0, which covers the whole AXI address space, to be accessible from secure and non-secure world the OP-TEE core memory would be accessible via memory aliasing. To prevent such attacks we need to ensure that region0 is accessible from the secure world only. Reviewed-by: Sahil Malhotra <sahil.malhotra@nxp.com> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
If OP-TEE is used the TZASC should be enabled to validate the memory access. This adds the initial support for the i.MX6 and i.MX8M to check if the TZASC is enabled and throw a panic if not. Once all platforms are covered this CFG_TZASC_CHECK_ENABLED should be removed and the check should be done by default to enforce that the TZASC is running. Reviewed-by: Sahil Malhotra <sahil.malhotra@nxp.com> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Move the region number handling into imx_tzc_auto_configure(), to make it possible to call the helper without ext. required context. This is required for the upcoming dynamic ddr size configuration. Reviewed-by: Sahil Malhotra <sahil.malhotra@nxp.com> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Currently all TZC drivers implement the nsec_ddr configuration via compile time configuration switches. This fact is not ideal for platforms which have various DRAM settings. OP-TEE already supports discovering the nsec_ddr chunks during the early boot process but doesn't expose this information. Therefore this foreach helper is added which can be used by the TZC drivers to address the above use-case. Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Reviewed-by: Sahil Malhotra <sahil.malhotra@nxp.com> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Convert the driver to use the new core_mmu_for_each_nsec_ddr() to allow dynamic configurations of the NS DRAM region(s). The DRAM configuration parsed by the OP-TEE core is either based on: - manifest-dt - external-dt - internal/embedded-dt - builtin compile-time defines This logic allows the imx-tzc380 driver to use the runtime information provided by an external DT. The compile-time builtin defines are used if no external DT is found or the external DT doesn't contain any memory information. For plat-imx this mapps to register_ddr(CFG_DRAM_BASE, CFG_DDR_SIZE), which is equivalent to imx_tzc_auto_configure(CFG_DRAM_BASE, CFG_DDR_SIZE, TZC_ATTR_SP_NS_RW). Reviewed-by: Sahil Malhotra <sahil.malhotra@nxp.com> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Document why the reconfiguration is required. Reviewed-by: Sahil Malhotra <sahil.malhotra@nxp.com> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Prior to this patch shdr_load_pub_key() didn't copy the subkey version when loading a subkey, effectively always reporting it as version 0 and disabling rollback protection. Fix this by extracting the subkey version when extracting the other field to enable the rollback protection. Fixes: c34d0d9 ("core: support loading TAs signed with a subkey") Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org> Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>
In mk/aosp_optee.mk the signed TA (.ta) is registered as an EXECUTABLES prebuilt, so AOSP runs check_elf_file on it. A signed TA is an ELF binary wrapped in a signed header and does not start with the ELF magic. On Android 17 the build no longer passes --skip-bad-elf-magic to check_elf_file, so this is now fatal: error: File "<uuid>.ta" must have a valid ELF magic word. Set LOCAL_CHECK_ELF_FILES := false for the .ta module in mk/aosp_optee.mk to skip this check. Signed-off-by: ming-jen.chang <ming-jen.chang@mediatek.com> Signed-off-by: Leo Chen <shf.chen@mediatek.com> Acked-by: Jens Wiklander <jenswi@kernel.org> Acked-by: Tadd Kao <tadd.kao@mediatek.com>
FIREWALL_DSU_RGN() is one register per region, not one register per channel. Move the register write out of the channel loop and use the current region as index instead of the channel loop counter. The practical effect of this bug was that the OP-TEE firewall setup destroyed the region that the TF-A had previously configured. TF-A protects the first MiB of address space from non secure access, due to the bug the region became visible again to non secure world. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Acked-by: Rouven Czerwinski <rouven.czerwinski@linaro.org>
The RK3506 shares UART0 between OP-TEE and the non-secure world (it is the Linux ttyS0 console). Enable the bounded serial8250 TX-empty flush added in commit de152e9 ("drivers: serial8250: bound the TX-empty poll in flush()") so a secure-world console write cannot spin a CPU forever while Linux contends the port, which would otherwise trip the non-secure hard-lockup watchdog. The flag depends on CFG_CORE_HAS_GENERIC_TIMER, which the platform already enables. Signed-off-by: Owen O'Hehir <oo.hehir@gmail.com> Acked-by: Etienne Carriere <etienne.carriere@st.com>
Add config to support arm smccc_trng for mt798x series please use mediatek public ATF. Link: https://github.com/mtk-openwrt/arm-trusted-firmware Signed-off-by: guan-gm.lin <guan-gm.lin@mediatek.com> Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
The manifest reservation logic assumes the FF-A manifest sits just below VCORE_START_VA, which only holds for the TF-A SP package layout used with Hafnium. Other SPMCs may place the manifest after the OP-TEE image, where assert(fdt < VCORE_START_VA) trips and fdt_max_size = VCORE_START_VA - fdt underflows. Drop that assert and use fdt_totalsize() (clamped to CFG_DTB_MAX_SIZE) as the manifest's max size so the reservation works regardless of where the SPMC places the manifest within OP-TEE's secure memory. Fixes: 414123a ("core: ffa: reserve physical memory for manifest") Signed-off-by: Sungbae Yoo <sungbaey@nvidia.com> Acked-by: Jens Wiklander <jenswi@kernel.org>
With LPAE, the user mapping must occupy an unused level 1 entry in the 32-bit VA range [1GB, 4GB[. An identity mapping can consume one of these entries while a randomized core mapping crosses a 1GB boundary and consumes the other two. The mappings do not overlap, so init_mem_map() accepts the layout, but set_user_va_idx() later asserts because no entry remains for a user mapping. Add an architecture-specific check for each tentative ASLR memory map, including the pending identity mapping. Reject candidates that leave no room for a user mapping and retry with the next candidate. Non-LPAE configurations retain their existing behavior. Fixes: 2317a39 ("core: lpae: search TAs VA base in the regions [1GB, 4GB[") Signed-off-by: Sungbae Yoo <sungbaey@nvidia.com> Reviewed-by: Jens Wiklander <jens.wiklander@oss.qualcomm.com>
Add CFG_SANITIZE_UNDEFINED_PANIC to control whether undefined behavior sanitizer reports should panic. This changes the default behavior from panicking to logging without panicking. Signed-off-by: Aleksandr Iashchenko <aleksandr.iashchenko@linutronix.de> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
UBSan instrumentation increases xlat table usage enough that UBSan-only builds can exhaust MAX_XLAT_TABLES during runtime mappings. Account for UBSan in the LPAE MAX_XLAT_TABLES calculation so both UBSan-only and ASan+UBSan configurations have enough xlat tables. Signed-off-by: Aleksandr Iashchenko <aleksandr.iashchenko@linutronix.de> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Add initial support for the CVA6 APU on the Genesys2 board. This includes two build flavors: - cv64a6_genesys_2: 64-bit variant, RV64IMAFDC ISA with Sv39 MMU. - cv32a6_genesys_2: 32-bit variant, RV32IMAC ISA with Sv32 MMU. Main platform specification: - CPU: Single-core OpenHW Group CVA6 CPU - ISA: RV64IMAFDC (64-bit) or RV32IMAC (32-bit) - MMU: Sv39 (64-bit), Sv32 (32-bit) - Timer: APB timer mapped at 0x18000000 with 4 interrupts - UART: ns16550 compatible, base 0x10000000 - CLINT: at 0x2000000 for timer and software interrupts - PLIC: at 0xc000000 with 30 devices - Memory: 1 GB DDR3 DRAM at 0x80000000 The secure memory region reserved for OP-TEE starts at address 0xBE000000 and is 16MB in size, placed near the top of the 1GB DRAM. Signed-off-by: Marouene Boubakri <marouene.boubakri@nxp.com> Acked-by: Alvin Chang <alvinga@andestech.com> Acked-by: Jens Wiklander <jens.wiklander@oss.qualcomm.com> Acked-by: Jerome Forissier <jerome.forissier@arm.com>
Extend the CI configuration to build the CVA6 platform alongside existing RISC-V platforms (virt, sifive, etc.). This ensures that future changes are validated against the CVA6 port as well. Signed-off-by: Marouene Boubakri <marouene.boubakri@nxp.com> Acked-by: Alvin Chang <alvinga@andestech.com> Acked-by: Jens Wiklander <jens.wiklander@oss.qualcomm.com> Acked-by: Jerome Forissier <jerome.forissier@arm.com>
The driver issues TRNG requests to the ASU firmware via the shared IPI queue, receiving up to 32 bytes of true random data per request. For callers requiring more than 32 bytes, the driver loops until the full length is satisfied. When CFG_WITH_SOFTWARE_PRNG is disabled (the default for this platform), hw_get_random_bytes() serves as the sole RNG source. When CFG_WITH_SOFTWARE_PRNG is enabled, plat_init_soft_prng() seeds the Fortuna PRNG with 64 bytes of hardware entropy from the ASU TRNG at boot. ASU module ID 0 (ASU_MODULE_TRNG_ID) is added to asu_client.h. The driver is gated on CFG_AMD_ASU_TRNG (default y). The ASU subsystem init is promoted from service_init to early_init_late so that it completes before service_init_crypto's tee_cryp_init() may call plat_init_soft_prng() -> hw_get_random_bytes() when CFG_WITH_SOFTWARE_PRNG=y, since service_init_crypto runs at a lower initcall level than the plain service_init level ASU previously used. Signed-off-by: Naganikhitha Kowlakuntla <Naganikhitha.Kowlakuntla@amd.com> Signed-off-by: Akshay Belsare <akshay.belsare@amd.com> Reviewed-by: Etienne Carriere <etienne.carriere@st.com> Acked-by: Jens Wiklander <jens.wiklander@oss.qualcomm.com>
Add Hardware Unique Key (HUK) support using AMD ASU. The driver fetches the 256-bit HUK from ASU firmware via IPI during boot, caches it for subsequent users, and derives the OP-TEE 128-bit HUK by hashing a labeled context string with the raw ASU HUK. Also adds a bounded wait when a concurrent fetch is in progress to avoid spurious readiness failures while preventing unbounded spinning if the firmware request stalls. When CFG_RPMB_FS is enabled, also implement plat_rpmb_key_is_ready() to gate first-boot RPMB authentication key provisioning on both the cached HUK being ready and the platform secure-state (SST) register reporting an operational lifecycle state (async or sync). Map the SST register on plat-versal2 and rename PLM_RTCA/PLM_RTCA_LEN to PLAT_SST_BASE/PLAT_SST_LEN to reflect this use. CFG_AMD_ASU_HUK is now forced to y whenever CFG_RPMB_FS is enabled. Signed-off-by: Akshay Belsare <akshay.belsare@amd.com> Acked-by: Jerome Forissier <jerome.forissier@arm.com> Acked-by: Jens Wiklander <jens.wiklander@oss.qualcomm.com>
…P_PAGE_COUNT The StMM SP heap size has been hardcoded to 402 pages (1.6 MiB), which is sufficient for minimal configurations but too small for builds that include UEFI Secure Boot. AuthVariableLib + VarCheckPolicyLib pull in OpenSSL, whose constructors exhaust the heap during MM initialization. Add CFG_STMM_HEAP_PAGE_COUNT to make the heap size configurable, defaulting to 402 pages to preserve existing behavior. Reject values below 402 at build time via static_assert(), as smaller values are known to break existing configurations. Platforms requiring Secure Boot can override the value (e.g., CFG_STMM_HEAP_PAGE_COUNT=800 for ~3.2 MiB) without forking OP-TEE. Link: OP-TEE#7728 Signed-off-by: Liz Fong-Jones <lizf@honeycomb.io> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Add support for GICv4 which is going to be enabled on the new wildcat target nord. Support for that will be added by subsequent patches. Assisted-by: Claude:claude-opus-4-8 Co-developed-by: Tyler Baker <tyler.baker@oss.qualcomm.com> Signed-off-by: Tyler Baker <tyler.baker@oss.qualcomm.com> Acked-by: Etienne Carriere <etienne.carriere@st.com> Reviewed-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Diagnostic logging depends on arch-specific DIAG_* addresses that are only defined for some Qualcomm chipsets. Compile diag_log.c only when CFG_QCOM_DIAG_LOG is enabled and provide no-op stubs otherwise, so platforms that do not define the DIAG_* memory regions still build. CFG_QCOM_DIAG_LOG is disabled by default; chipsets that support it opt in via their target.mk. Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Nord is also referenced as IQ-10 as the marketing name, more details about the platform can be found on link below. It is based on wildcat architecture and base support is being added for 18 Oryon cores along with GICv4. Assisted-by: Claude:claude-opus-4-8 Link: https://www.qualcomm.com/internet-of-things/products/iq10-series Co-developed-by: Tyler Baker <tyler.baker@oss.qualcomm.com> Signed-off-by: Tyler Baker <tyler.baker@oss.qualcomm.com> Reviewed-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Add PLATFORM=qcom-nord build to the CI. Reviewed-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Add ECC and ECDH support through the AMD ASU crypto firmware driver path. This driver enables hardware-accelerated ECDSA and ECDH operations for the following curves: - NIST P-192 - NIST P-224 - NIST P-256 - NIST P-384 - NIST P-521 Signed-off-by: Sunil Vaghela <Sunilkumar.JagdishbhaiVaghela@amd.com> Signed-off-by: Shubham Soni <shubham.manojsoni@amd.com> Signed-off-by: Akshay Belsare <akshay.belsare@amd.com> Acked-by: Jens Wiklander <jens.wiklander@oss.qualcomm.com>
Recent ASUFW reorders and repads several request structs. Mirror the new layout so ECC requests are accepted. This exposed a latent cache-coherency bug. FW DMA buffers were stack-allocated at sizes that are not a multiple of a cache line, so their trailing partial line was shared with adjacent stack data. The payload-sized invalidate after the FW response is promoted to clean-and-invalidate on that partial line and writes stale neighbour bytes back over the FW-produced key material. This affected only P-521; as it is the only curve whose key sizes land in the trailing partial line. Move the FW-shared buffers off the stack via a small helper that uses memalign(CACHELINE_LEN, ROUNDUP(len, CACHELINE_LEN)) so each buffer owns whole cache lines, and release them with free_wipe() to zeroize secrets before freeing. Fixes xtest pkcs11_1019.18 (ECDSA P-521 sign/verify). Signed-off-by: Sunil Vaghela <Sunilkumar.JagdishbhaiVaghela@amd.com> Signed-off-by: Akshay Belsare <akshay.belsare@amd.com> Acked-by: Jens Wiklander <jens.wiklander@oss.qualcomm.com>
Use put_dirh_primitive in ree_fs_closedir_rpc() to decrement counter even if ree_fs_dirh is already closed. This aligns the behaviour of ree_fs_closedir_rpc() with ree_fs_close(). For the same reasons as ree_fs_close() we need to call put_dirh_primitive() in ree_fs_closedir_rpc() as there is no call to get_dirh() and there might be a case where ree_fs_dirh can be NULL. Fixes: 7ae1573 ("core: ree_fs: fix dirfile handle refcount") Signed-off-by: Thomas Bourgoin <thomas.bourgoin@foss.st.com> Reviewed-by: Jens Wiklander <jens.wiklander@oss.qualcomm.com>
ree_fs_readdir_rpc() might fail when you try to enumerate for files. In this case tee_fs_dirfile_get_next() return TEE_ERROR_ITEM_NOT_FOUND. But since res is used to know if we need to close dirh or not, we will close dirh for the wrong reason. Fixes: 7ae1573 ("core: ree_fs: fix dirfile handle refcount") Signed-off-by: Thomas Bourgoin <thomas.bourgoin@foss.st.com> Reviewed-by: Jens Wiklander <jens.wiklander@oss.qualcomm.com>
Add an OP-TEE platform flavor for the Rockchip RV1106G3, a single-core ARMv7-A Cortex-A7 SoC, verified on the Luckfox Pico Ultra. The port reuses the existing plat-rockchip infrastructure and the shared ARMv7 plat_init.S / core_pos_a32.S reset hooks (the same ones rk322x uses). It adds the RV1106 memory map, the firewall (FW_DDR) programming that hardware-isolates TZDRAM from the non-secure CPU (CFG_RV1106_TEE_HW_ISOLATE), secure initialisation and the non-secure world hand-off. As a single-core SoC it enables CFG_PSCI_ARM32 but uses the generic __weak PSCI defaults rather than the rk322x multi-core back end. Signed-off-by: Owen O'Hehir <oo.hehir@gmail.com> Acked-by: Jens Wiklander <jens.wiklander@oss.qualcomm.com>
Add support for ECB,CBC,CTR modes of AES algorithm. Driver supports offload of 128 and 256 bit key sizes requests. 192 bit key size requests are offloaded to software fallback. Signed-off-by: Harish Ediga <harish.ediga@amd.com> Signed-off-by: Akshay Belsare <akshay.belsare@amd.com> Reviewed-by: Etienne Carriere <etienne.carriere@st.com> Acked-by: Jens Wiklander <jens.wiklander@oss.qualcomm.com>
Add OP-TEE RSA driver that uses ASUFW for HW accelerated RSA operations. This implementation adds support of below points: - PKCS#1 v2.1 PSS sign and verify - Public raw encrypt - Private raw decrypt - Public OAEP encrypt - Private OAEP decrypt Supported key sizes are 2048-bit, 3072-bit, and 4096-bit. Signed-off-by: Shubham Soni <shubham.manojsoni@amd.com> Signed-off-by: Akshay Belsare <akshay.belsare@amd.com> Acked-by: Jens Wiklander <jens.wiklander@oss.qualcomm.com>
Add ta_dev_kit_conf, which exports conf.h, conf.mk and conf.cmake. They are written by plain shell commands, so this target compiles nothing and completes in about a second, unlike ta_dev_kit, which builds the libraries too. It is meant for dev kit consumers that need the configuration before they can build anything: optee_test picks its sources from the CFG_* flags it reads from the dev kit conf.mk, and some build systems have to know their sources before any rule can run. Signed-off-by: Andrii Shtompel <andrii_shtompel@epam.com>
Run ta_dev_kit_conf while the makefiles are parsed, so that the configuration is on disk before any Android.mk is read; building the dev kit itself is left to the graph as before. The md5 of the generated conf.mk is kept in a variable so that ckati parses again when the configuration changes, even though it comes from files ckati never reads itself. All optee_os invocations now share one command line, so the configuration read while parsing cannot drift from the one the dev kit is built with. This is for the Android.mk files which select what to build from the CFG_ flags of the dev kit, as optee_test does for its GP socket tests. They read them with -include $(TA_DEV_KIT_DIR)/host_include/conf.mk, which finds nothing on a clean build: ckati parses the makefiles to emit the ninja graph, and the dev kit is built by that very graph. The flags then come out empty and the sources they select are dropped with no diagnostic, so what ends up in the binary depends on whether the output directory is warm. No build dependency can fix this, as the parsing is what produces the rules. Signed-off-by: Andrii Shtompel <andrii_shtompel@epam.com>
andrew2311
marked this pull request as draft
August 3, 2026 12:24
Author
|
Need to merge from rcar-gen5_4.4.0-xt-android branch |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fix xtest link error in android (by exposing optee_os conf.mk)
Original PR OP-TEE#7897
Adds ta_dev_kit_conf, a target that exports the dev kit configuration
(conf.h, conf.mk, conf.cmake): the files are written by shell commands, so
it builds no libraries and takes about a second. mk/aosp_optee.mk then
runs it while the makefiles are parsed, so the configuration is on disk
before any Android.mk is read. Building the dev kit itself is left to the
ninja graph, as before.
The md5 of the generated conf.mk is kept in a variable, so ckati re-parses
when the configuration changes, even though that configuration comes from
files ckati never reads itself. All optee_os invocations now share one
command line, so the configuration read while parsing cannot drift from the
one the dev kit is built with.
This fixes a long-standing trap for Android.mk files that select what to
build from the CFG_ flags of the TEE they are built against -
-include $(TA_DEV_KIT_DIR)/host_include/conf.mk, as optee_test does for its
GP socket tests. On a clean build that include finds nothing, because ckati
parses the makefiles to emit the ninja graph and the dev kit is built by
that very graph: the flags come out empty and the sources they select are
dropped with no diagnostic, so what ends up in the binary depends on whether
the output directory happens to be warm. It was reported as
OP-TEE/optee_test#275 in 2018 and closed without a fix; no build dependency
can close it, since the parsing is what produces the rules. The approach
here is the one @jforissier suggested in OP-TEE/optee_test#825, making the
dev kit configuration a required input.