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