Re: [meta-ti][master][PATCH v5 0/3] Add LUKS encryption with fTPM support

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