Newbie questions #28
Comments
I'll have to defer to @bebon901 for that - a venv is almost certainly the right path forward, but if you're willing to live (slightly) dangerously, you could install the Debian Trixie versions of Textual. We were caught out by the lack of updates to Textual in the Debian project - Bookworm ships with a horrendously old version, which is where you'll be seeing problems.
No images are written to CM4 at all - but your device runs through the entire state machine, generating a keywriter payload, a fastboot payload, and the modified partitions. I introduced the flag to allow developers iterating on the process (or indeed, on their base OS) to inspect intermediates ahead of writes. As the writes can take a while (they're very much size dependant), this was a concrete productivity win.
This is the expected flow when DEMO_MODE_ONLY is set - as no image is actually written, the automatic reboot commands are not transferred. You shouldn't need to disconnect the jumper pins at any time during provisioning.
This looks like fastboot has failed to open your cryptroot. That's a missing DEMO_MODE_ONLY wrapper, so that's definitely something we should fix. I can see you had DEMO_MODE_ONLY set from these lines:
Yes - if you've only set provisioner to run in DEMO_MODE, then it will not result in a bootable eMMC.
At the simplest level:
I am, however, about to cut a release for the HSM initial functionality, so you might be better served by waiting. |
|
v1.0.2 is now released - including the monitoring and configuration apps. DEMO_MODE_ONLY fix will move into v1.0.3, due next week. |
|
That great , we will give it a try |
|
@torntrousers I believe v1.1.0 will now have resolved your outstanding questions - let me know how you get on. |
|
thanks, will go give it a try .. |
|
One of my colleagues was the one who tried the 1.1.0 release and rasied #45 which i see is now closed. Bit unclear to me from looking at the issue tracker if things are all good to try now or should i wait for the 1.2.0 release, and if so what sort of time frame might that be? |
|
I'd strongly encourage waiting for 1.2.0 - we're addressing a major concern in the pre-boot authentication image, and while HEAD is in a much better shape I'm still reticent to suggest moving forward without the updated cryptroot. I'm expecting to cut that release either this week or early next week (possibly even breaking my Don't Deploy On Fridays! rule). |
|
with the 1.1.1 release we've i think successfully setup a CM4 with secure boot. yay, thank you. Is there as easy way to see it really is? lsblk shows the root partition is using crypto_LUKS, i can see there is a boot.sig in the /boot/firmware directory. Is there some command that shows the cm4 is using really secure boot or the efuse is correctly set or something, couldn't see anything in dmesg? |
|
The best way to determine if secure boot is being enforced by the bootloader is probably to have the payload check. There's a bit of documentation (https://github.com/raspberrypi/documentation/blob/a4826cbba4190ffb376026a5e7726c5c9d3fe9ee/documentation/asciidoc/computers/configuration/device-tree.adoc?plain=1#L931) around a field in the /chosen/bootloader device tree file, which gets populated by the system. Note that you can also use that to perform a safety check in a deployed image - if you ever see that not being true, abort execution/fire flares/call home. |
|
Secondly, you can ask rpiboot to fetch device metadata - which will include a hash of the customer OTP, under the 'CUSTOMER_KEY_HASH' field of the resultant JSON. If you ask rpi-sb-provisioner to provision your device again - and do so with RPI_DEVICE_FETCH_METADATA configured - you'll get the metadata as part of the provisioning flow in |
Could that 8 mean "The customer public key digest has been written to OTP", but i'm not sure its in the correct place? |
|
I believe you need to interpret that output as a byte-swapped u32 (so, you can't just directly map it into binary). In this case, the '09' should be taken as the LSB, and 09 is bits 0 and 3 set - so:
|
|
@torntrousers Assuming you're happy with the explanations so far, I'm going to close this issue so we can fracture out new questions into individual issues. |
Hello, i'm trying to use this to provision a device and have some questions:
I can't get the TUI commands to work, config.sh and monitor.sh. I see there is an open issue about the Textual dependencies but is there any way to use these commands in the meantime?
It's not so clear what happens when DEMO_MODE_ONLY is set - does any image at all get written to the CM4 or can you only do the triage phase?
The triage phase seems to work ok and the keywriter log ends with "Keywriting completed. Rebooting for next phase." and then nothing happens. Is that supposed to be an automatic reboot or must I manually power cycle the CM4? Thats what i end up doing, should the the disable eMMC Boot pins jumper be connected for this or not?
Eventually power cycling without the jumper on the provisioner phase seems to run and the end of the log shows this:
and thats it and nothing else happens. not clear if its finished ok or not? Eventually rebooting the CM4 with a HDMI screen attached shows this:
so it doesn't seem to have made the eMMC bootable?
In the end i'd like to be able to test out the HSM support from #20 (comment) but thats not yet out in a release. Do i need to somehow make my own build from the latest code, and if so how would i do that?
The text was updated successfully, but these errors were encountered: