On 3/18/26 21:42, Andrew Davis wrote: > 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? >
You are right, I misquoted it. The OP-TEE APIs are standard, not TI-specific. Following Denys's recommendation I have moved recipes to dynamic-layers/security/ making this conditionally available on meta-security presence. Thanks, Shiva > 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/20260305172115.3684326-1- >>>>> [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/20260304193824.2495898-1- >>>>> [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/20260302144647.1705408-1- >>>>> [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 (#19771): https://lists.yoctoproject.org/g/meta-ti/message/19771 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]] -=-=-=-=-=-=-=-=-=-=-=-
