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

On 3/18/26 9:47 AM, Shiva Tripathi wrote:
> 
> 
> 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.

Which means they will also be available in any layers that depend on
meta-it-bsp such as meta-arago..

> This LUKS module implementation
> is K3-specific, relies on TI's OP-TEE implementation and uses K3
> hardware features.

How does this rely on TI's OP-TEE? The API's exposed from our OP-TEE
are all standard APIs. I'm not seeing what part of this is actually
TI specific?

Andrew

> 
> 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
>>
>>
>>
>