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. > > > 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? > > > > 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? > > > > - 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... > > > > - 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 > > > > 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. > > 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... > > > > - 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 -- Jonathan Cormier Senior Software Engineer Office: 315.425.4045 x222 http://www.CriticalLink.com 6712 Brooklawn Parkway, Syracuse, NY 13211
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19757): https://lists.yoctoproject.org/g/meta-ti/message/19757 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]] -=-=-=-=-=-=-=-=-=-=-=-
