U-Boot hardening doesn't work on BSP images

[MMG-DG]

There seems to be some issues with the set of whitelisted commands.

I am using an im8xmp verdin SoM. My build is based on the tdxref default manifest configuration (not the TorizonOS one). I have added the INHERT = "tdx-signed" and other variables to use my custom certs and keys.

However, after closing the device I am unable to boot it. I have now got a patch that sets my open allowed list to the same as the closed list so I can more easily debug and still flash new images using TEZI.

What I have found out is that my boot_cmd to load from mmc includes the use of part uuid which is only listed as CMD_CAT_PART_READ. I believe 0001-toradex-common-add-command-whitelisting-modules.patch should include the CMD_CAT_NEEDED category so that it is an allowed command during boot. Changing this one value appears to work for me, but not sure how to prepare a change and PR for this fix (I am a noob at yocto things).

Here is essentially what is being run to load the mmc2 root partition:

env set uuid_set 'part uuid ${root_devtype} ${root_devnum}:${root_part} uuid'
env set rootfsargs_set 'run uuid_set && env set rootfsargs root=PARTUUID=${uuid} ro rootwait'

[sergioprado]

@MMG-DG thanks for reporting and debugging the issue.

Maybe some recent change in the Toradex BSP caused this. Your proposed fix makes sense to me.

@rborn-tx what do you think?

[rborn-tx]

@sergioprado Have we tested booting tdxref with hardening enabled? If so, then we should have seen messages saying that some command didn't pass the whitelist (which would prevent the boot when the device was closed). From the warnings, we should evaluate whether or not the commands are always safe and, if so, add them to the whitelist. This would require code changes so it would be normally be done by us at Toradex.

Users who decide to customize the boot script shouldn't need to do something like that; instead they would configure the set of allowed commands via the control FDT even on a compiled image (but we don't have the tooling for that yet and that's why this is not yet documented).

Maybe some recent change in the Toradex BSP caused this.

Checking the tdxref boot script I don't see recent changes. Thus my feeling is that we may have overlooked warning messages when testing tdxref.

[rborn-tx]

@MMG-DG, you mentioned the device no longer booted after it was closed. I'm sorry to hear that.

Weren't warning messages shown on the console before the device was closed? You should have seen messages such as:

Command execution denied (blocked by category) for `part uuid mmc 0:2...`.

Similar problem would happen with the kernel command line protection.

By the way, I've just notice that the tdxref boot script is setting the kernel command line dynamically. This will most certainly cause issues with the kernel command line protection as well. Considering that, maybe the best solution for you at the moment is to disable the hardening in your Yocto config if building tdxref (in your local.conf for example):

TDX_UBOOT_HARDENING_ENABLE:forcevariable = "0"

If you are not enabling the rootfs protection (via dm-verity) the hardening doesn't add much value anyways.

Beware that all the hardening is currently tuned for Torizon OS images. Due to this, bumps are expected for other images, at least for now. We expect to improve this situation in the future.

Now, let me ask you something: have you considered using the Torizon OS minimal in your project, rather than tdxref? There all the hardening should work out of the box plus many other features such as remote and offline updates. The rootfs protection on Torizon OS is not implemented yet but it's an ongoing effort that we expect to finish in the near future.

[MMG-DG]

@rborn-tx - I will have to double check, but I don't think we have any issues with the UBOOT hardening part. In response to the question about the warnings... I am new to the project I am working on (which is 9 months behind schedule at present). I was told it was all good, but found that not to be the case for the first SoM I flashed and fused. However, I have been digging into it all to figure out what was done and how to fix it. As I am new to this project and the fact the initial delivery date is roughly 1 month away, I don't have the time now to review the Use of TorizonOS, but it is already something I have suggested as a high-priority item for our v2 release and as such that may be the way we go after initial release. For this project our requirement is pretty much "if it can be secured it MUST be secured" (naturally that is coming from powers that are either not technical, or know what is generally possible in linux environments and throwing around buzz words).

P.S. Just messaged a colleague who worked on the initial builds and he says that warning never showed as the "open" definition is basically to allow all commands. I have just run a build with a patch to set the open value to be the same as the closed value so that at least we can see these warnings early and not brick any more SoMs.

P.P.S. Something else we have been looking at is using caam within u-boot to do encryption of the full rootfs (which seems to require some dek... commands. Is there and easy way for me to add these if/when needed to our layer? maybe as a conditional patch. What would be nice is if we could have a yocto variable that is expanded to generate the command definitions, so any custom layers can just append extra safe, unsafe and needed definitions.

[sergioprado]

@sergioprado Have we tested booting tdxref with hardening enabled?

@rborn-tx actually I was about to ask you that. When I worked in secure boot for iMX devices the hardening feature was not implemented yet and when I worked on secure boot for AM62 the hardening feature was not tested since it is disabled by default. Remeber that when this feature was developed and merged, I was not part of the security team. So yeah, I didn't have a chance to test this in a BSP image. And based on your answer, I guess when thjis feature was developed, only Torizon OS was tested. Is that right? If so, I would recommend to disable this feature by default in this layer, until this is properly tested in BSP builds. Does that make sense to you?

@MMG-DG while we don't have the hardening properly tested for BSP images, I would recommend you to just disabled it by adding the following line to a configuration file, as already recommended by Rogerio:

TDX_UBOOT_HARDENING_ENABLE:forcevariable = "0"

[MMG-DG]

Just to be sure... When you say "BSP images", you mean the TorizonOS ones only? We are using the tdx-reference-minimal-image as our base and building on top of that. Is this not a BSP image?

[sergioprado]

@MMG-DG sorry, there was a mistake in my previous message (that I edited). What I meant to say: while we don't have the hardening properly tested for BSP images, I would recommend you to just disabled it.

We are using the tdx-reference-minimal-image as our base and building on top of that. Is this not a BSP image?

Yes, this is considered a BSP image. The summary is that, since the U-Boot hardening feature was only tested on Torizon OS, you can disable it for now.

[MMG-DG]

Unfortunately, my project specifically states we have to use it and have it turned on. The only issue we had with doing this was that single needed command (part uuid) in the whitelist when closing the device. If that single change makes it into this repo, then as far as my overlords are concerned it is working for our use case and I will have to continue with everything as is.

[rborn-tx]

@sergioprado

And based on your answer, I guess when thjis feature was developed, only Torizon OS was tested. Is that right?

That's right.

If so, I would recommend to disable this feature by default in this layer, until this is properly tested in BSP builds. Does that make sense to you?

That's likely the best we can do for now since our focus is Torizon OS. But let's discussed it internally.

[rborn-tx]

I built a tdx-reference-minimal-image and ran it to get the following message on the console:

...
   Uncompressing Kernel Image
   Loading Device Tree to 000000007dee9000, end 000000007defc4cc ... OK
## WARNING: Required node "/chosen/toradex,secure-boot" could not be found in device-tree.
## WARNING: Allowing boot while device is open; please fix bootargs before closing device.
...

Due to the lack of the device-tree node mentioned above (which comes from a special overlay called <MACHINE>-secboot-kargs_overlay.dtbo) the hardening is actually disabled. After I manually added the said overlay to overlays.txt in the image I got a different message:

## WARNING: Initial part of passed bootargs string (A) does not match 'required-bootargs' property (B) in device-tree.
##  A: "root=PARTUUID=f1065cb0-02 ro rootwait console=tty1 console=ttymxc0,115200 consoleblank=0 earlycon"
##  B: "root=PARTUUID=7ad80ede-02 ro rootwait console=tty1 console=ttymxc0,115200 consoleblank=0 earlycon"
## WARNING: Allowing boot while device is open; please fix bootargs before closing device.

Still, I didn't get messages complaining about commands not passing the whitelist which is definitely an issue.

Anyways, the above shows that even if we added "part uuid" to the needed list, one would still face problems with booting the tdxref image with hardening enabled, in this case related to the kernel arguments protection. Solving that part would be a bit harder because the tdxref image passes a variable argument part which must be validated by U-Boot.

@MMG-DG So, unfortunately, at the moment the hardening is not really usable with the BSP images. The short term solution is just disabling it as we suggested before. By doing so you still get a full chain of trust (if you care about the buzzword :smile:) if using the tdxref-signed class, even though the chain can be broken under special circumstances.

Thanks again for reporting the problem!

[rborn-tx]

As a temporary solution I created a PR disabling hardening on any images but Torizon OS. Also I created a follow up issue for ensuring warnings are shown if the bootloader executes commands that wouldn't be allowed on closed state.

With this, maybe we could close the present issue?

[sergioprado]

Unfortunately, my project specifically states we have to use it and have it turned on.

@MMG-DG interesting. Would you please elaborate more on why this is a requirement for your project?

[MMG-DG]

Because a sales-person decided to sell it that way and add an extra tick-box to our requirements list. Probably the same person who dictated that we should not use TorizonOS in the first place. However, that is where we are for my current project until we get past our initial release, at which point I can re-evaluate previous decisions and make better proposals for the next iteration.

[MMG-DG]

Hi,

It's me again.... I am now back on testing this part of the build (deadline tomorrow), and I just want to try and confirm some things....

based on previous reply about messages on the console:

   Uncompressing Kernel Image
   Loading Device Tree to 000000007dee9000, end 000000007defc4cc ... OK
## WARNING: Required node "/chosen/toradex,secure-boot" could not be found in device-tree.
## WARNING: Allowing boot while device is open; please fix bootargs before closing device.

and

## WARNING: Initial part of passed bootargs string (A) does not match 'required-bootargs' property (B) in device-tree.
##  A: "root=PARTUUID=f1065cb0-02 ro rootwait console=tty1 console=ttymxc0,115200 consoleblank=0 earlycon"
##  B: "root=PARTUUID=7ad80ede-02 ro rootwait console=tty1 console=ttymxc0,115200 consoleblank=0 earlycon"
## WARNING: Allowing boot while device is open; please fix bootargs before closing device.

I am not seeing anything like these at all. I have set my fuses (except the final one) for the certificates. I am seeing no HAB issues, but I am also still seeing hab fuse not enabled. Is this right? or should this say something else? I was expecting something else as I have set everything except the last fuse to make Secure Boot a no-return thing.

I also don't see any warnings like you do. I am sure I am missing something, but not sure what. Here is a brief extract of what I see in the console:

U-Boot SPL 2022.04-6.7.0-devel+git.7588eb559ca2 (May 28 2024 - 11:19:14 +0000)
DDRINFO: start DRAM init
DDRINFO: DRAM rate 4000MTS
DDRINFO:ddrphy calibration done
DDRINFO: ddrmix config done
DDR configured as dual rank
SEC0:  RNG instantiated
Normal Boot
WDT:   Started watchdog@30280000 with servicing (60s timeout)
Boot Stage: Primary boot
Find img info 0x&48026c00, size 20480
Need continue download 19456
Download 883712, Total size 903712
hab fuse not enabled

Authenticate image from DDR location 0x401fadc0...
NOTICE:  BL31: v2.6(release):lf_v2.6-g3c1583ba0a
NOTICE:  BL31: Built : 11:00:38, Nov 21 2022
[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[    0.000000] Linux version 5.15.148-6.7.0-devel+git.f437ddb7191d (oe-user@oe-host) (aarch64-tdx-linux-gcc (GCC) 11.4.0, GNU ld (GNU Binutils) 2.38.20220708) #1 SMP PREEMPT Wed May 15 17:04:15 UTC 2024
[    0.000000] Machine model: Toradex Verdin iMX8M Plus WB on Verdin Development Board
[    0.000000] efi: UEFI not found.
[    0.000000] Reserved memory: created CMA memory pool at 0x00000000de000000, size 512 MiB
[    0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
[    0.000000] earlycon: ec_imx6q0 at MMIO 0x0000000030880000 (options '')
[    0.000000] printk: bootconsole [ec_imx6q0] enabled
[    0.000000] NUMA: No NUMA configuration found
[    0.000000] NUMA: Faking a node at [mem 0x0000000040000000-0x000000013fffffff]
[    0.000000] NUMA: NODE_DATA [mem 0x13f796800-0x13f798fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000040000000-0x00000000ffffffff]
[    0.000000]   DMA32    empty
[    0.000000]   Normal   [mem 0x0000000100000000-0x000000013fffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000040000000-0x000000013fffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x000000013fffffff]
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv1.1 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: MIGRATE_INFO_TYPE not supported.
[    0.000000] psci: SMC Calling Convention v1.2
[    0.000000] percpu: Embedded 19 pages/cpu s38936 r8192 d30696 u77824
[    0.000000] Detected VIPT I-cache on CPU0
[    0.000000] CPU features: detected: GIC system register CPU interface
[    0.000000] CPU features: detected: ARM erratum 845719
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 1032192
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: root=PARTUUID=5fe27906-02 ro rootwait console=tty1 console=ttymxc2,115200 consoleblank=0 earlycon
[    0.000000] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes, linear)
[    0.000000] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes, linear)
[    0.000000] mem auto-init: stack:off, heap alloc:on, heap free:on
[    0.000000] mem auto-init: clearing system memory may take some time...
[    0.000000] software IO TLB: mapped [mem 0x00000000da000000-0x00000000de000000] (64MB)
[    0.000000] Memory: 3493776K/4194304K available (17216K kernel code, 1712K rwdata, 6492K rodata, 3136K init, 508K bss, 176240K reserved, 524288K cma-reserved)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.000000] rcu: Preemptible hierarchical RCU implementation.
[    0.000000] rcu:     RCU event tracing is enabled.
[    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=4.
[    0.000000]  Trampoline variant of Tasks RCU enabled.
[    0.000000]  Tracing variant of Tasks RCU enabled.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[    0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[    0.000000] GICv3: GIC: Using split EOI/Deactivate mode
[    0.000000] GICv3: 160 SPIs implemented
[    0.000000] GICv3: 0 Extended SPIs implemented
[    0.000000] GICv3: Distributor has no Range Selector support
[    0.000000] Root IRQ handler: gic_handle_irq
[    0.000000] GICv3: 16 PPIs implemented
[    0.000000] GICv3: CPU0: found redistributor 0 region 0:0x0000000038880000
[    0.000000] ITS: No ITS available, not enabling LPIs
[    0.000000] arch_timer: cp15 timer(s) running at 8.00MHz (phys).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1d854df40, max_idle_ns: 440795202120 ns
[    0.000000] sched_clock: 56 bits at 8MHz, resolution 125ns, wraps every 2199023255500ns
[    0.008632] Console: colour dummy device 80x25
[    0.012999] printk: console [tty1] enabled
[    0.016701] Calibrating delay loop (skipped), value calculated using timer frequency.. 16.00 BogoMIPS (lpj=32000)
[    0.026966] pid_max: default: 32768 minimum: 301
[    0.031649] LSM: Security Framework initializing
[    0.036330] Mount-cache hash table entries: 8192 (order: 4, 65536 bytes, linear)
[    0.043676] Mountpoint-cache hash table entries: 8192 (order: 4, 65536 bytes, linear)
[    0.053177] rcu: Hierarchical SRCU implementation.
[    0.057274] EFI services will not be available.
[    0.061185] smp: Bringing up secondary CPUs ...
[    0.065965] Detected VIPT I-cache on CPU1
[    0.065992] GICv3: CPU1: found redistributor 1 region 0:0x00000000388a0000
[    0.066032] CPU1: Booted secondary processor 0x0000000001 [0x410fd034]
[    0.066529] Detected VIPT I-cache on CPU2
[    0.066551] GICv3: CPU2: found redistributor 2 region 0:0x00000000388c0000
[    0.066574] CPU2: Booted secondary processor 0x0000000002 [0x410fd034]
[    0.067041] Detected VIPT I-cache on CPU3
[    0.067063] GICv3: CPU3: found redistributor 3 region 0:0x00000000388e0000
[    0.067082] CPU3: Booted secondary processor 0x0000000003 [0x410fd034]
[    0.067152] smp: Brought up 1 node, 4 CPUs
[    0.122082] SMP: Total of 4 processors activated.
[    0.126797] CPU features: detected: 32-bit EL0 Support
[    0.131979] CPU features: detected: CRC32 instructions
[    0.137168] CPU features: emulated: Privileged Access Never (PAN) using TTBR0_EL1 switching
[    0.154267] CPU: All CPU(s) started at EL2
[    0.155536] alternatives: patching kernel code
[    0.161482] devtmpfs: initialized
[    0.176819] KASLR disabled due to lack of seed
[    0.178589] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.188257] futex hash table entries: 1024 (order: 4, 65536 bytes, linear)
[    0.273963] pinctrl core: initialized pinctrl subsystem
[    0.276980] DMI not present or invalid.
[    0.280835] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[    0.295914] DMA: preallocated 512 KiB GFP_KERNEL pool for atomic allocations
[    0.300568] DMA: preallocated 512 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
[    0.308456] DMA: preallocated 512 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
[    0.315983] audit: initializing netlink subsys (disabled)
[    0.321542] audit: type=2000 audit(0.248:1): state=initialized audit_enabled=0 res=1
[    0.322048] thermal_sys: Registered thermal governor 'step_wise'
[    0.329140] thermal_sys: Registered thermal governor 'power_allocator'
[    0.335476] cpuidle: using governor menu
[    0.345923] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
[    0.352580] ASID allocator initialised with 65536 entries
[    0.358227] Serial: AMBA PL011 UART driver
[    0.362105] imx mu driver is registered.
[    0.365974] imx rpmsg driver is registered.
[    0.383326] imx8mp-pinctrl 30330000.pinctrl: initialized IMX pinctrl driver
[    0.399153] platform 32e80000.lcd-controller: Fixing up cyclic dependency with 32e60000.mipi_dsi
[    0.411891] platform 32fd8000.hdmi: Fixing up cyclic dependency with 32fc6000.lcd-controller
[    0.437267] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages
[    0.441182] HugeTLB registered 32.0 MiB page size, pre-allocated 0 pages
[    0.447926] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
[    0.454634] HugeTLB registered 64.0 KiB page size, pre-allocated 0 pages
[    0.462677] cryptd: max_cpu_qlen set to 1000
[    0.469045] ACPI: Interpreter disabled.
[    0.471952] iommu: Default domain type: Translated 
[    0.474960] iommu: DMA domain TLB invalidation policy: strict mode 
[    0.481610] SCSI subsystem initialized
[    0.485373] usbcore: registered new interface driver usbfs
[    0.490562] usbcore: registered new interface driver hub
[    0.495883] usbcore: registered new device driver usb
[    0.502096] mc: Linux media interface: v0.10
[    0.505253] videodev: Linux video capture interface: v2.00
[    0.510802] pps_core: LinuxPPS API ver. 1 registered
[    0.515718] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.524925] PTP clock support registered
[    0.529049] EDAC MC: Ver: 3.0.0
[    0.533159] FPGA manager framework
[    0.535495] Advanced Linux Sound Architecture Driver Initialized.
[    0.542806] clocksource: Switched to clocksource arch_sys_counter
[    0.547850] VFS: Disk quotas dquot_6.6.0
[    0.551659] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    0.558699] pnp: PnP ACPI: disabled
[    0.569130] NET: Registered PF_INET protocol family
[    0.571308] IP idents hash table entries: 65536 (order: 7, 524288 bytes, linear)
[    0.580235] tcp_listen_portaddr_hash hash table entries: 2048 (order: 3, 32768 bytes, linear)
[    0.587272] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear)
[    0.595000] TCP established hash table entries: 32768 (order: 6, 262144 bytes, linear)
[    0.603170] TCP bind hash table entries: 32768 (order: 7, 524288 bytes, linear)
[    0.610762] TCP: Hash tables configured (established 32768 bind 32768)
[    0.616948] UDP hash table entries: 2048 (order: 4, 65536 bytes, linear)
[    0.623671] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes, linear)
[    0.630965] NET: Registered PF_UNIX/PF_LOCAL protocol family
[    0.636916] RPC: Registered named UNIX socket transport module.
[    0.642421] RPC: Registered udp transport module.
[    0.647138] RPC: Registered tcp transport module.
[    0.651861] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.659098] hw perfevents: enabled with armv8_cortex_a53 PMU driver, 7 counters available
[    0.670922] Initialise system trusted keyrings
[    0.672675] workingset: timestamp_bits=42 max_order=20 bucket_order=0
[    0.685817] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.689484] NFS: Registering the id_resolver key type
[    0.693950] Key type id_resolver registered
[    0.698105] Key type id_legacy registered
[    0.702217] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    0.708879] nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver Registering...
[    0.716456] 9p: Installing v9fs 9p2000 file system support
[    0.757403] Key type asymmetric registered
[    0.758658] Asymmetric key parser 'x509' registered
[    0.763614] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 243)
[    0.771006] io scheduler mq-deadline registered
[    0.775547] io scheduler kyber registered
[    0.784552] EINJ: ACPI disabled.
[    0.794236] mxs-dma 33000000.dma-apbh: initialized
[    0.797564] SoC: i.MX8MP revision 1.1
[    0.800499] Bus freq driver module loaded
[    0.810935] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    0.816882] 30860000.serial: ttymxc0 at MMIO 0x30860000 (irq = 34, base_baud = 1500000) is a IMX
[    0.823796] 30880000.serial: ttymxc2 at MMIO 0x30880000 (irq = 35, base_baud = 1500000) is a IMX
[    0.832120] printk: console [ttymxc2] enabled
[    0.832120] printk: console [ttymxc2] enabled
[    0.840760] printk: bootconsole [ec_imx6q0] disabled
[    0.840760] printk: bootconsole [ec_imx6q0] disabled
[    0.851195] 30890000.serial: ttymxc1 at MMIO 0x30890000 (irq = 36, base_baud = 1500000) is a IMX
[    0.879612] brd: module loaded
[    0.887503] loop: module loaded
[    0.898426] tun: Universal TUN/TAP device driver, 1.6
[    0.904924] usbcore: registered new device driver r8152-cfgselector
[    0.911260] usbcore: registered new interface driver r8152
[    0.916922] VFIO - User Level meta-driver version: 0.3
[    0.927925] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    0.934554] ehci-platform: EHCI generic platform driver
[    0.940086] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    0.946308] ohci-platform: OHCI generic platform driver
[    0.952524] usbcore: registered new interface driver uas
[    0.957902] usbcore: registered new interface driver usb-storage
[    0.963996] usbcore: registered new interface driver usbserial_generic
[    0.970561] usbserial: USB Serial support registered for generic
[    0.976611] usbcore: registered new interface driver ftdi_sio
[    0.982395] usbserial: USB Serial support registered for FTDI USB Serial Device
[    0.989751] usbcore: registered new interface driver usb_serial_simple
[    0.996313] usbserial: USB Serial support registered for carelink
[    1.002447] usbserial: USB Serial support registered for flashloader
[    1.008834] usbserial: USB Serial support registered for funsoft
[    1.014871] usbserial: USB Serial support registered for google
[    1.020824] usbserial: USB Serial support registered for hp4x
[    1.026603] usbserial: USB Serial support registered for kaufmann
[    1.032733] usbserial: USB Serial support registered for libtransistor
[    1.039296] usbserial: USB Serial support registered for moto_modem
[    1.045596] usbserial: USB Serial support registered for motorola_tetra
[    1.052242] usbserial: USB Serial support registered for nokia
[    1.058106] usbserial: USB Serial support registered for novatel_gps
[    1.064495] usbserial: USB Serial support registered for siemens_mpi
[    1.070880] usbserial: USB Serial support registered for suunto
[    1.076833] usbserial: USB Serial support registered for vivopay
[    1.082874] usbserial: USB Serial support registered for zio
[    1.088575] usbcore: registered new interface driver usb_ehset_test
[    1.095178] usbcore: registered new device driver onboard-usb-hub
[    1.105120] input: 30370000.snvs:snvs-powerkey as /devices/platform/soc@0/30000000.bus/30370000.snvs/30370000.snvs:snvs-powerkey/input/input0
[    1.120168] snvs_rtc 30370000.snvs:snvs-rtc-lp: registered as rtc1
[    1.126550] i2c_dev: i2c /dev entries driver
[    1.136177] device-mapper: ioctl: 4.45.0-ioctl (2021-03-22) initialised: dm-devel@redhat.com
[    1.144909] EDAC MC: ECC not enabled
[    1.150094] sdhci: Secure Digital Host Controller Interface driver
[    1.156302] sdhci: Copyright(c) Pierre Ossman
[    1.161244] Synopsys Designware Multimedia Card Interface Driver
[    1.168105] sdhci-pltfm: SDHCI platform and OF driver helper
[    1.177019] ledtrig-cpu: registered to indicate activity on CPUs
[    1.184159] SMCCC: SOC_ID: ARCH_SOC_ID not implemented, skipping ....
[    1.191956] caam 30900000.crypto: device ID = 0x0a16040100000100 (Era 9)
[    1.198708] caam 30900000.crypto: job rings = 2, qi = 0
[    1.207709] mmc2: SDHCI controller on 30b60000.mmc [30b60000.mmc] using ADMA
[    1.226698] caam algorithms registered in /proc/crypto
[    1.232979] caam 30900000.crypto: caam pkc algorithms registered in /proc/crypto
[    1.240513] caam 30900000.crypto: rng crypto API alg registered prng-caam
[    1.247335] caam 30900000.crypto: registering rng-caam
[    1.253747] Device caam-keygen registered
[    1.259305] usbcore: registered new interface driver usbhid
[    1.264910] usbhid: USB HID core driver
[    1.274229] mmc2: new HS400 Enhanced strobe MMC card at address 0001
[    1.274926]  cs_system_cfg: CoreSight Configuration manager initialised
[    1.281459] mmcblk2: mmc2:0001 IX2932 29.1 GiB 
[    1.289670] random: crng init done
[    1.290669] hantrodec 0 : module inserted. Major = 235
[    1.291181] hantrodec 1 : module inserted. Major = 235
[    1.292228] hantroenc: HW at base <0000000038320000> with ID <0x80006200>
[    1.295659]  mmcblk2: p1 p2 p3 p4
[    1.300554] hx280enc: module inserted. Major <234>
[    1.307793] mmcblk2boot0: mmc2:0001 IX2932 4.00 MiB 
[    1.317948] NET: Registered PF_LLC protocol family
[    1.321739] mmcblk2boot1: mmc2:0001 IX2932 4.00 MiB 
[    1.326106] NET: Registered PF_INET6 protocol family
[    1.331380] mmcblk2rpmb: mmc2:0001 IX2932 4.00 MiB, chardev (237:0)
[    1.336829] Segment Routing with IPv6
[    1.350309] In-situ OAM (IOAM) with IPv6
[    1.354302] NET: Registered PF_PACKET protocol family
[    1.360179] 8021q: 802.1Q VLAN Support v1.8
[    1.364500] 9pnet: Installing 9P2000 support
[    1.368819] tsn generic netlink module v1 init...
[    1.373615] Key type dns_resolver registered
[    1.378579] Loading compiled-in X.509 certificates
[    1.390809] Loaded X.509 cert 'Build time autogenerated kernel key: f060c2f64935e45cda8d2a3b0907544ea0539f16'
[    1.401325] Key type trusted registered
[    1.428745] +V3.3_SD: supplied by +V3.3_SW
[    1.446144] nxp-pca9450 0-0025: pca9450bc probed.
[    1.452387] rtc-ds1307 0-0032: oscillator failed, set time!
[    1.458437] rtc-ds1307 0-0032: registered as rtc0
[    1.463491] rtc-ds1307 0-0032: hctosys: unable to read the hardware clock
[    1.473129] at24 0-0050: supply vcc not found, using dummy regulator
[    1.480085] at24 0-0050: 256 byte 24c02 EEPROM, writable, 16 bytes/write
[    1.486879] i2c i2c-0: IMX I2C adapter registered
[    1.492796] i2c i2c-1: IMX I2C adapter registered
[    1.498596] i2c 2-000f: Fixing up cyclic dependency with 32e40000.csi
[    1.505560] i2c 2-0021: Fixing up cyclic dependency with 32e50000.csi
[    1.512380] i2c i2c-2: IMX I2C adapter registered
[    1.518777] i2c 3-0048: Fixing up cyclic dependency with 32e60000.mipi_dsi
[    1.525751] i2c 3-0048: Fixing up cyclic dependency with hdmi-connector
[    1.533136] i2c i2c-3: IMX I2C adapter registered
[    1.538592] imx8mq-usb-phy 381f0040.usb-phy: supply vbus not found, using dummy regulator
[    1.566682] pps pps0: new PPS source ptp0
[    1.578191] fec 30be0000.ethernet eth0: registered PHC device 0
[    1.585099] clk: failed to reparent hsio_axi to sys_pll2_500m: -16
[    1.596007] clk: failed to reparent hsio_axi to sys_pll2_500m: -16
[    1.602916] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller
[    1.608453] xhci-hcd xhci-hcd.1.auto: new USB bus registered, assigned bus number 1
[    1.616539] xhci-hcd xhci-hcd.1.auto: hcc params 0x0220fe65 hci version 0x110 quirks 0x0000002001010010
[    1.625996] xhci-hcd xhci-hcd.1.auto: irq 79, io mem 0x38200000
[    1.632079] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller
[    1.637590] xhci-hcd xhci-hcd.1.auto: new USB bus registered, assigned bus number 2
[    1.645269] xhci-hcd xhci-hcd.1.auto: Host supports USB 3.0 SuperSpeed
[    1.652986] hub 1-0:1.0: USB hub found
[    1.656793] hub 1-0:1.0: 1 port detected
[    1.661073] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
[    1.670290] hub 2-0:1.0: USB hub found
[    1.674087] hub 2-0:1.0: 1 port detected
[    1.678653] imx-cpufreq-dt imx-cpufreq-dt: cpu speed grade 7 mkt segment 2 supported-hw 0x80 0x4
[    1.690488] mxc-mipi-csi2-sam 32e40000.csi: supply mipi-phy not found, using dummy regulator
[    1.691970] sdhci-esdhc-imx 30b50000.mmc: Got CD GPIO
[    1.699366] : mipi_csis_imx8mp_phy_reset, No remote pad found!
[    1.709950] mxc-mipi-csi2-sam 32e40000.csi: lanes: 4, hs_settle: 13, clk_settle: 2, wclk: 1, freq: 500000000
[    1.720734] mxc-mipi-csi2-sam 32e50000.csi: supply mipi-phy not found, using dummy regulator
[    1.723667] mmc0: SDHCI controller on 30b40000.mmc [30b40000.mmc] using ADMA
[    1.729609] : mipi_csis_imx8mp_phy_reset, No remote pad found!
[    1.742248] mxc-mipi-csi2-sam 32e50000.csi: lanes: 1, hs_settle: 13, clk_settle: 2, wclk: 1, freq: 108000000
[    1.744032] mmc1: SDHCI controller on 30b50000.mmc [30b50000.mmc] using ADMA
[    1.753821] isi-capture 32e00000.isi:cap_device: deferring 32e00000.isi:cap_device device registration
[    1.768618] mxc-isi 32e00000.isi: mxc_isi.0 registered successfully
[    1.776432] isi-capture 32e02000.isi:cap_device: deferring 32e02000.isi:cap_device device registration
[    1.785895] mxc-isi 32e02000.isi: mxc_isi.1 registered successfully
[    1.793945] On-module +V3.3_ETH: supplied by On-module +V3.3 (BUCK4)
[    1.890433] mmc0: new ultra high speed SDR104 SDIO card at address 0001
[    2.010069] dwhdmi-imx 32fd8000.hdmi: Detected HDMI TX controller v2.13a with HDCP (samsung_dw_hdmi_phy2)
[    2.020804] dwhdmi-imx 32fd8000.hdmi: registered DesignWare HDMI I2C bus driver
[    2.030237] imx-dwmac 30bf0000.ethernet: IRQ eth_lpi not found
[    2.037042] imx-dwmac 30bf0000.ethernet: User ID: 0x10, Synopsys ID: 0x51
[    2.043865] imx-dwmac 30bf0000.ethernet:     DWMAC4/5
[    2.048668] imx-dwmac 30bf0000.ethernet: DMA HW capability register supported
[    2.055830] imx-dwmac 30bf0000.ethernet: RX Checksum Offload Engine supported
[    2.062978] imx-dwmac 30bf0000.ethernet: Wake-Up On Lan supported
[    2.069150] imx-dwmac 30bf0000.ethernet: Enable RX Mitigation via HW Watchdog Timer
[    2.076826] imx-dwmac 30bf0000.ethernet: Enabled L3L4 Flow TC (entries=8)
[    2.083631] imx-dwmac 30bf0000.ethernet: Enabled RFS Flow TC (entries=8)
[    2.090368] imx-dwmac 30bf0000.ethernet: Enabling HW TC (entries=256, max_off=256)
[    2.097955] imx-dwmac 30bf0000.ethernet: Using 34 bits DMA width
[    2.113624] input: gpio-keys as /devices/platform/gpio-keys/input/input1
[    2.142413] ALSA device list:
[    2.145418]   No soundcards found.
[    2.158748] EXT4-fs (mmcblk2p2): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[    2.168808] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[    2.179202] devtmpfs: mounted
[    2.183105] Freeing unused kernel memory: 3136K
[    2.187740] Run /sbin/init as init process
[    2.333839] systemd[1]: systemd 250.5+ running in system mode (-PAM -AUDIT -SELINUX -APPARMOR -IMA -SMACK -SECCOMP -GCRYPT -GNUTLS +OPENSSL -ACL +BLKID -CURL -ELFUTILS -FIDO2 -IDN2 -IDN -IPTC -KMOD -LIBCRYPTSETUP +LIBFDISK -PCRE2 -PWQUALITY -P11KIT -QRENCODE -BZIP2 -LZ4 -XZ -ZLIB -ZSTD -BPF_FRAMEWORK -XKBCOMMON -UTMP -SYSVINIT default-hierarchy=hybrid)
[    2.365968] systemd[1]: Detected architecture arm64.

Welcome to TDX Wayland with XWayland 6.7.0-devel-20240703125556+build.0 (kirkstone)!

Does this look correct to you, or is there something missing? Fingers crossed you can point me in the right direction before I potentially break another SoM.

[MMG-DG]

Just a quick update.....

I have managed to find those warnings. What I saw was the same initial warning. After adding the overlay manually as mentioned above I got:

## WARNING: Initial part of passed bootargs string (A) does not match 'required-bootargs' property (B) in device-tree.
##  A: "root=PARTUUID=c8a19fa8-02 ro rootwait console=tty1 console=ttymxc2,115200 consoleblank=0 earlycon"
##  B: "root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3"
## WARNING: Allowing boot while device is open; please fix bootargs before closing device.

So this will certainly not work with the reference image we are using. I assume we would need to look at relevant modifications to label the rootfs partition and make the relevant changes in the overlay to match what is generated for our boot command.

On another note I see there is a "quiet" flag in the overlay. What does this do? This may be something we want to add in a future revision of our kernel build. I am guessing it reduces the output of the boot information.

[MMG-DG]

OK, after a lot of testing and playing I think we can close this issue. This is definitely not going to work without a fair amount of thinking :-) If/when I get some time, I may look into what is happening and see if I can make this a bit more generic to work for the other images (unless the powers-that-be decide to just go with TorizonOS for the next round of images).

[rborn-tx]

Disabling the hardening as I said at the beginning would be the easiest at the moment.

Another possibility would be disabling only the kernel command line protection (which is the part of the hardening that is harder to make work on the BSP reference images). We don't have an option for that but you could do it by adding a config fragment to u-boot setting CONFIG_TDX_BOOTARGS_PROTECTION=n.

Anyways, we do have plans to make the hardening work on BSP reference images, but that it's a low priority task that may take a while to be scheduled. In the long term I'd suggest consider switching to Torizon OS so you get all of the secure boot features plus many others for free.

[sergioprado]

@MMG-DG, as @rborn-tx mentioned, we have the hardening feature in our backlog. As soon as it gets some priority, we will work on it.

For now, I will leave this issue opened. It is a honest bug report of a feature documented but that currently doesn't work. Hopefully we can fix that soon.

Thanks again for reporting!

[sergioprado]

Obs: I just changed the title of the issue to describe better the problem.

[thepinkmile]

Hi, FYI: this is MMG_DG, from one of my home accounts.

I have setup several test for some of the options mentioned here. These have hopefully been tested while I was on holiday by my team. Depending on the results, I may have a branch I can create a PR on that disabled the bootargs protection on non-torizon builds.

I have also been working on a patch and some changes that should (if they work), enable the bootargs ability for the base BSP images (tdx minimal and multimedia reference images).

In the long run, I think we will be looking to eventually swap to torizon os. At which point I will probably have a million questions on how that works 😁

[sergioprado]

Sounds good, thanks for the update!

[MMG-DG]

Merry Christmas,

I have been working on this for a while now and wanted to quickly run a "theory" past you guys....

Note: I have added TDX_UBOOT_SILENT_ENABLE to add the extra silencing of u-boot we require (e.g. adding silent=1 to bootargs via a patch).

If I add a u-boot-distro-boot.bbappend with the following to my layer:

TDX_UBOOT_SILENT_ENABLE ?= "0"
TDX_UBOOT_ROOTFS_IDENTIFIER ?= "root=/dev/\x24{root_devtype}blk\x24{root_devnum}p\x24{root_part} rootfstype=${TEZI_ROOT_PART_TYPE}"
TDX_UBOOT_CONSOLE_BOOTARGS ?= "${@oe.utils.conditional('TDX_UBOOT_SILENT_ENABLE', '1', 'console=null', 'console=ttymxc2,115200', d)}"

do_deploy:prepend() {
    sed -i \
        -e 's/console=\x24{console},\x24{baudrate}/${TDX_UBOOT_CONSOLE_BOOTARGS}/g' \
        -e '/env set uuid_set/d' \
        -e 's/run uuid_set && //g' \
        -e "s@rootfsargs root=PARTUUID=\x24{uuid} ro@rootfsargs ${TDX_UBOOT_ROOTFS_IDENTIFIER} ro@g" \
        -e "s@echo \"Booting from \x24{devtype} failed!\" && false@echo \"Booting from \x24{devtype} failed!\" && reset@" \
        "${WORKDIR}/boot.cmd.in"
}

Note: the reset in the last change above I believe will force the system to reset instead of jumping into the u-boot init prompt (which was highlighted in our security review as a bad thing as it potentially allows a way to break the secure boot process).

Also in my conf/local.conf I added:

TDX_SECBOOT_REQUIRED_BOOTARGS = "${TDX_UBOOT_ROOTFS_IDENTIFIER} ro rootwait console=tty1 ${TDX_UBOOT_CONSOLE_BOOTARGS} consoleblank=0 earlycon"
TEZI_EXTERNAL_KERNEL_DEVICETREE_BOOT:append = "${TDX_SECBOOT_KARGS_OVERLAY}.dtbo"

Then the bootargs verification seems to work fine. This also removes the use of part uuid which avoids the original issue I had with the whitelisting.

Does this look correct? or is there a better way to do this?

FYI, once I have finished my current project release process I will clean-up the branch I have and submit possible PR with the changes to support this.

My only other question is if it is possible to apply these changes only when :torizonis NOT in the overrides? As that way it will not affect the Torizon builds as you already do what is required there for it to work.

Regards, MMG

[sergioprado]

@MMG-DG as far as I understood, this is another approach to hardening U-Boot, by disabling the command-line prompt and limiting the parameters passed to the kernel at build time, am I right?

Are you implementing this on top of the U-Boot hardening feature we have, or to substitute it?

[MMG-DG]

@sergioprado - This is to make what you have for the hardening work on the base BSP reference images (currently our build uses the reference minimal image).

The main issue was the validation of the kernel bootargs. However, with these changes (which I will have in my fork soon and will create a PR for officially) I can get everything to work for the u-boot hardening.

The only caveat at the moment is that I also force the addition of :torizon into the overrides so the code to prevent the hardening on the bsp images is side-stepped while I am testing it all. My hope is that if this is cleaned up and my PR gets accepted then this layer will be able to work on all the tdx images as well as torizon.

[rborn-tx]

Hi @MMG-DG, let me give you some feedback on this:

Note: the reset in the last change above I believe will force the system to reset instead of jumping into the u-boot init prompt (which was highlighted in our security review as a bad thing as it potentially allows a way to break the secure boot process).

If you're using the CLI access prevention feature that is part of the hardening then U-Boot would not enter its CLI once the boot script is finished (e.g. if it does not succeed in booting the OS), so you wouldn't need to concern yourself much about this in the boot script.

However, to highlight a feature of our hardening implementation, preventing access to the CLI is not strictly needed to ensure the secure boot process can't be broken. I mean, even if an attacker gets access to the CLI they wouldn't be able to do anything other than execute authentic/signed software in the end (unless we missed something, which would be considered a but). Thus the CLI access prevention is just an extra layer of security which is generally nice to have, but not essential to the solution.

TDX_UBOOT_ROOTFS_IDENTIFIER ?= "root=/dev/\x24{root_devtype}blk\x24{root_devnum}p\x24{root_part} rootfstype=${TEZI_ROOT_PART_TYPE}"

Also in my conf/local.conf I added: TDX_SECBOOT_REQUIRED_BOOTARGS = "${TDX_UBOOT_ROOTFS_IDENTIFIER} ro rootwait console=tty1 ${TDX_UBOOT_CONSOLE_BOOTARGS} consoleblank=0 earlycon" TEZI_EXTERNAL_KERNEL_DEVICETREE_BOOT:append = "${TDX_SECBOOT_KARGS_OVERLAY}.dtbo"

A major problem I see here is that TDX_UBOOT_ROOTFS_IDENTIFIER depends on variables whose value are set at runtime ($root_devtype/devnum). Thus an attacker who's able to modify the U-Boot environment would also be able to inject kernel arguments by setting those variables. As a general principle you don't want anything depending on runtime variables to be present in TDX_SECBOOT_REQUIRED_BOOTARGS.

Thus the challenge becomes figuring out a way to boot the system with a fixed kernel command-line. In fact this may not even be possible. In case of Torizon OS, most of the kernel command-line is fixed (including the selection of the boot partition by name (which depends on a ramdisk in order to work)) but we need a variable part to specify which OSTree to boot. To solve this, we keep the fixed part of the kargs inside the kargs overlay and the variable part is separately validated by U-Boot (as part of the hardening). This is described in our hardening docs (Kernel command-line protection).

I haven't thought of how to solve the problem for BSP images in general, so I can't really suggest an approach at the moment; this would be result of an investigation where the maintenance effort would need to be taken into account.

Anyways, if you want the hardening working for your use case in the short term then I'd suggest considering only allowing boot to a specific block device/partition in which case you would pass a fixed root=/dev/... argument to the kernel. You'ds still bump into the fatal error saying the hardening is only tested with Torizon OS images, but we could perhaps change that into a warning. What do you think?

[MMG-DG]

@rborn-tx - 1) in relation to the CLI access prevention: this is quite possible as the version we initially sent for testing was while the U-Boot hardening was disabled (due to the change where it only applies to torizon images). Once I have that all working we will getting it re-tested and can possibly confirm if that works. 2) I assume by the hardening prevention you also include the signing of the rootfs? Which is not currently possible in our case (due to the rootfs then being read-only; something we will be fixing in version 2 of our images), so my question here would be... In this case would it not still be possible to cause U-Boot to load an alternative rootfs? 3) In the case of TDX_UBOOT_ROOTFS_IDENTIFIER... I have actually used more variables for the mention uboot ones in my local version for exactly that reason, but just left the uboot variables in place as an example of what values are actually going in there. So this should not be a problem, I just don't know if any of those values differ in other modules as I only have access to the iMX8MP. However, I guess this would be something we would add to the machine configs and then inject as proper yocto variables here instead?

With all of those bits in place it does appear to work and successfully boots after blowing the secure-boot fuse. So for our implementation it is good enough. I would however prefer to try and make it as generic as possible before merging any changes in a PR (once I have that ready maybe it would be good to get some input on that part).

Regards, MMG

[rborn-tx]

@MMG-DG

1. in relation to the `CLI access prevention`: this is quite possible as the version we initially sent for testing was while the U-Boot hardening was disabled (due to the change where it only applies to torizon images). Once I have that all working we will getting it re-tested and can possibly confirm if that works.

Feedback is always appreciated :slightly_smiling_face:

2. I assume by the hardening prevention you also include the signing of the rootfs? Which is not currently possible in our case (due to the rootfs then being read-only; something we will be fixing in version 2 of our images), so my question here would be... In this case would it not still be possible to cause U-Boot to load an alternative rootfs?

The hardening is concerned with what we call the basic chain of trust (BCoT) which means all boot chain up to when the kernel FIT image is loaded and the kernel executed by U-Boot; i.e. it doesn't cover the rootfs. Notice that U-Boot does not "load" a rootfs, it simply passes information to the kernel indicating the block device to be used for the root mount (if a ramdisk is not in use (is that your case?)). The kernel command line protection is responsible for preventing changes to the kernel arguments that could be used to switch to another rootfs. That's another reason for passing a fixed root=... rather than leaving this parameter to be determined dynamically at runtime.

3. In the case of `TDX_UBOOT_ROOTFS_IDENTIFIER`... I have actually used more variables for the mention uboot ones in my local version for exactly that reason, but just left the uboot variables in place as an example of what values are actually going in there. So this should not be a problem, I just don't know if any of those values differ in other modules as I only have access to the iMX8MP. However, I guess this would be something we would add to the machine configs and then inject as proper yocto variables here instead?

Simply preventing a different rootfs to be selected provides very little protection. For this security layer I'm leaning towards assuming the rootfs protection is in use so that the rootfs could be taken from anywhere as long as it is signed. With this we keep both security and flexibility.

With all of those bits in place it does appear to work and successfully boots after blowing the secure-boot fuse. So for our implementation it is good enough. I would however prefer to try and make it as generic as possible before merging any changes in a PR (once I have that ready maybe it would be good to get some input on that part).

---

Regarding this whole topic, I have good news: we are about to start working on making hardening officially work on BSP images. So, stay tuned!

[thepinkmile]

Hi,

Am I correct in thinking there was a merge for changes to support this now? If so, once my current sprint is over I will be looking to “re-pin” to the latest commit and start removing my custom changes and revert to using your implementation.

Also, I believe I can use the new encryption-key-location “partition” changes and hopefully then turn on the signed rootfs settings for a FCoT.

Getting excited that I may be able to delete a lot of my code soon. lol.

After that we will be looking to migrate to the Scarthgap branches and start testing that.

so much to do and not enough time.

Thanks for everything you guys are doing. Regards, MMG

[sergioprado]

@thepinkmile yes the support for U-Boot hardening on iMX based modules is merged on both scarthgap and kirkstone branches.

@rborn-tx can this issue be closed now?

[rborn-tx]

can this issue be closed now?

@sergioprado I hope to do it soon. Though the feature implementation should be done, I wanted to confirm if the expected kernel arguments are correctly set at least for some other machines.

[rborn-tx]

@sergioprado It seems it will take a while until we have automated builds and tests for the BSP images with secure boot. Considering that, I thought of closing this issue right now since, as I said, in theory the work is done even though it has not been tested on most machines. Then if anyone reports related issues we could reopen it or create a new one. How does that sound?

[sergioprado]

@rborn-tx sounds good! Let's consider the feature implemented and close this issue. Any bugs found, we handle it in a separate issue.