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? > 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? 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19746): https://lists.yoctoproject.org/g/meta-ti/message/19746 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]] -=-=-=-=-=-=-=-=-=-=-=-
