On 3/18/26 19:42, Jon Cormier wrote: > I am following this discussion as its pretty relevant to us trying to > get a full end to end secure boot implementation. > > On Tue, Mar 17, 2026 at 3:52 PM Denys Dmytriyenko <[email protected]> wrote: >> >> Sorry for the delay and thanks for waiting! >> >> Below are some high-level questions and comments I've got reviewing your >> patches.
Hi Denys, Jon Thanks for the review. Adding my comments below: >> >> >> On Fri, Mar 06, 2026 at 10:07:32PM +0530, Shiva Tripathi via >> lists.yoctoproject.org wrote: >>> This patch series adds LUKS full disk encryption support using firmware TPM >>> (fTPM) for TI K3 platforms. The implementation provides hardware-backed >>> encryption with keys sealed by TPM running in OP-TEE and stored in eMMC >>> RPMB. >> >> What are the HW requirements for this implementation? >> Does it work on any K3 platform, even GP, or does it require an HS variant? >> What about eMMC requirement? >> Yes eMMC with RPMB is mandatory for this implementation to work since the TPM sealed key (handle 0x81080001) is stored in RPMB, leveraging the replay-attack protection. Since OPTEE FTPM is enabled for K3 [1], this implementation is applicable for all K3 platforms (GP and HS both inclusive). It would make more sense to use it for HS devices with authenticated boot chain present, and fTPM based encryption providing a better security model. [1]: https://github.com/YoeDistro/meta-ti/blob/master/meta-ti-bsp/conf/machine/include/k3.inc#L41 >> >>> Background: >>> TI K3 platforms do not have integrated discrete TPM hardware. To provide >>> TPM 2.0 functionality, this implementation uses firmware TPM (fTPM) - a >>> Trusted Application running in OP-TEE secure world. The fTPM provides >>> standard TPM 2.0 interfaces while leveraging ARM TrustZone for isolation >>> and eMMC RPMB (Replay Protected Memory Block) for secure persistent storage. >>> >>> Key features: >>> - Conditional builds: Enabled via DISTRO_FEATURES += "luks" with >>> MACHINE_FEATURES as 'optee-ftpm' >> >> Why is it being added to meta-ti? This seems heavily distro-specific, maybe >> even product-specific... >> >> Moreover, there are run-time dependencies on TPM packages that are not in any >> of the layers that meta-ti depends on. >> >> In order to enable this feature, you'd need to add a corresponding layer to >> bblayers.conf - should this at a minimum go into a dynamic-layer? >> >> The reason to keep it in meta-ti is, optee-ftpm recipes and TI K3 OP-TEE integration are already in meta-ti-bsp. This LUKS module implementation is K3-specific, relies on TI's OP-TEE implementation and uses K3 hardware features. Agree, we can move it to dynamic-layers/security. I'll shorty send the v6 patches with this change. >>> - No impact on default SDK builds >> >> Since this is disabled by default, this never gets built by the CI/CD and >> hence, there's no way to ensure future changes don't break this. >> Arguably, there are other features that are not enabled by default >> (jailhouse, falcon), so it may be a moot point... >> Agree with your concern, we are planning to automate testing for this feature starting from am62x platforms. But it's not there in place today. >> >>> - In-place encryption on first boot >>> - TPM persistent handle for key storage (0x81080001) >>> - Secure key storage in eMMC RPMB via OP-TEE >>> - Security model similar to CIP Core >>> >>> Use case: >>> This is designed for K3 platforms requiring secure boot and encrypted >> >> How are you protecting boot partition from getting tampered with? >> Besides encrypting rootfs, are there any other Secure Boot steps taken to >> protect the boot flow from a MITM attack? > The guides for secure booting u-boot and the kernel are pretty decent. > But currently it gets a bit fuzzy when it gets to securing the > filesystem. And integrating that with Yocto. The current guide > instead of encrypting in place, copies the unencrypted rootfs data > into a new encrypted partition during first boot. And the encryption > key isn't protected at all. So this does seem like a positive step > forward. > https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/11_02_08_02/exports/docs/linux/Foundational_Components/System_Security/Auth_boot.html Boot partition isn't protected in this implementation. This is data-at-rest encryption only. For a complete secure boot flow, this should be combined with TI's secure boot (ROM → SPL → U-Boot → FIT image verification), as highlighted by Jon. Secure Boot + LUKS: Protects against boot tampering + data theft >> >> >>> storage, such as industrial automation, automotive, and IoT gateways where >>> discrete TPM chips are cost-prohibitive but security requirements demand >>> hardware-backed encryption. >>> >>> Testing: >>> - Tested on AM62x platform with kernel 6.18 >>> - First boot: Successful in-place LUKS encryption >> >> Have you considered pre-encrypting the image during the build and then >> only changing the key, if needed, on the first boot? > Would that be any faster? I'd assume re-encrypting with a new key > would take just as long if not more than encrypting once. I have followed the CIP core's security model approach here, which does in-place encryption to avoid shipping images with shared encryption key. I think approach you are suggesting would make use of updating LUKS keyslots (dummy with TPM key) but i am not very confident about it at moment - on speed and any new security attack surface it exposes. Would it be fine to take the in-place encryption approach time being ? We can do more analysis on the method you are suggesting and improve going ahead. >> >> How long does it take to encrypt the rootfs on the first boot? I would >> imagine >> it being very expensive operation to encrypt and overwrite the entire >> partition. >> >> Also, have you considered binding the key to a PCR, so it is not easily >> extractable during a MITM attack? >> >> Anyway, I'm guessing this is just a sample implementation of this one >> particular feature - encrypted rootfs - and not a complete Secure Boot ready >> for production... >> I see "17.4 MiB/s" as the encryption speed. For a minimal image (~ 315 MiB) it takes around 17 seconds. Binding key to PCR would be a next phase improvement. We haven't enabled measured boot too yet, in the current series keys are sealed to TPM. Yes, the whole idea of this implementation is to give a reference to users who want to use hardware backed solution with RPMB and fTPM and perform disk encryption. They'll have to analyze their security model requirements and fine tune this reference implementation. Thanks, Shiva >> >>> - Subsequent boots: Successful TPM unsealing and boot >>> >>> The series is structured as follows: >>> 1. Kernel configuration for LUKS and crypto support >>> 2. LUKS encryption initramfs module with fTPM key management >>> 3. Initramfs generation trigger and packagegroup with dual gating >>> >>> --- >>> Changes in v5: >>> - change from MACHINE_FEATURES 'luks-encryption' to DISTRO_FEATURES 'luks' >>> - implement dual gating using existing MACHINE_FEATURES 'optee-ftpm' >>> - optimize kernel config - remove unnecessary CBC, ECB, ESSIV, LRW, PCBC, >>> SHA256_ARM64 >>> - packagegroup-ti-core-initramfs.bb changes moved to patch 3 from patch2 >>> - Link to v4: >>> https://lore.kernel.org/all/[email protected]/ >>> >>> Changes in v4: >>> - remove encrypted-boot-common.inc and use existing ti-core-initramfs.inc >>> - Link to v3: >>> https://lore.kernel.org/all/[email protected]/ >>> >>> Changes in v3: >>> - remove separate sdimage.wks for encrypted boot, default works >>> - update encrypted-boot-common.inc to use existing hook for adding >>> TI_CORE_INITRAMFS_ENABLED dependency on luks-encryption flag >>> - add logic to verify if partition has enough space for LUKS header before >>> starting encryption >>> >>> Changes in v2: >>> - changes to use existing ti-core-initramfs instead of adding separate >>> - cleanup in previous init script as per comments in v1 >>> - /usr/bin/busybox logs updated to echo, mesg, info >>> - WORKDIR changed to UNPACKDIR >>> - Link to v1: >>> https://lore.kernel.org/all/[email protected]/ >>> >>> Shiva Tripathi (3): >>> linux-ti-staging: Add LUKS encryption config >>> initramfs: Add LUKS encryption module with fTPM >>> ti-core-initramfs: Enable initramfs for LUKS encryption >>> >>> .../machine/include/ti-core-initramfs.inc | 2 +- >>> .../linux/linux-ti-staging-6.18/luks-ftpm.cfg | 22 ++ >>> .../linux/linux-ti-staging_6.18.bb | 9 + >>> .../initramfs-module-luks-ftpm/luksftpm | 341 ++++++++++++++++++ >>> .../initramfs-module-luks-ftpm_1.0.bb | 41 +++ >>> .../packagegroup-ti-core-initramfs.bb | 3 + >>> 6 files changed, 417 insertions(+), 1 deletion(-) >>> create mode 100644 >>> meta-ti-bsp/recipes-kernel/linux/linux-ti-staging-6.18/luks-ftpm.cfg >>> create mode 100644 >>> meta-ti-bsp/recipes-ti/initramfs/initramfs-module-luks-ftpm/luksftpm >>> create mode 100644 >>> meta-ti-bsp/recipes-ti/initramfs/initramfs-module-luks-ftpm_1.0.bb >>> >>> -- >>> 2.34.1 > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19758): https://lists.yoctoproject.org/g/meta-ti/message/19758 Mute This Topic: https://lists.yoctoproject.org/mt/118173650/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/meta-ti/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
