Closed tlaurion closed 6 years ago
Building to see if there is enough place for it in the 4mb image.
What's the value in having it in the flasher image, versus the full image? Once the user has flashed the system with the full image, they need to reboot to take ownership of the TPM, install their gpg keys, seal the disk keys, etc.
What's the value in having it in the flasher image, versus the full image? Not flash 3 times, just 2. Else, reflashing the ROM invalidates measurements and rollback counter anyway. Two steps is more straightforward then 3 steps, even logically, no?
Once the user has flashed the system with the full image, they need to reboot to take ownership of the TPM, install their gpg keys, seal the disk keys, etc. They can now generate and inject their keys into downloaded reproducible rom with cbfs within a secured environment: Heads.
1- Inside x230-flash Heads rom: Generate keys to mounted external media. Export armored keys to mounted external media. With the help of cbfs tool, add armored keys + distribution trusted signatures + ssh authorized keys inside of downloaded/built reproducible rom into mounted external media. Flash user modified rom from mounted external media through flashrom-x230.sh helper script. Unmount external media. Reboot. 2-Inside x230 Heads rom Take ownership of TPM. (Take TPMTOP picture on the second reboot only.) Boot from USB iso. Install OS. Reboot. Select new default boot, sign config, seal disk keys in one step, the keys already being present.
Done. Upgrading rom from within Heads extracts user keys and inject them into downloaded/built reproducible rom, prior to flashing it, thanks to @flammit.
Le lun. 7 mai 2018 11:30, Trammell Hudson notifications@github.com a écrit :
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/osresearch/heads/issues/402#issuecomment-387103553, or mute the thread https://github.com/notifications/unsubscribe-auth/AAygsnZwWUWIHENDoqR8zs5pHavUq8lvks5twGisgaJpZM4T0Mm1 .
I for one would question the x230-flash config in general, and the 4m/8m split. It suggests flashing the 8m image which is not usable.
I'd document flashing any 4m-coreboot-distribution-image and (or only) unlock the IFD on the 8m chip, and moving to a full Heads from there, something like this.
Anyways, please never depend on having x230-flash actually flashed!
@merge agreed that having the 8MB chunk from the full 12MB x230 image is a bit misleading and should probably be removed. x230-flash isn't required, just usually the fastest if you're externally flashing the first time.
I often use the 4M x230-flash image to recover bricked systems. It is also the easiest way to configure the Heads runtime would be within the runtime (since then you won't need a compiled cbfstool).
The skulls install docs are quite good, so if you have suggestions for the Heads docs please PR to the heads-wiki =)
I agree that the x230 board target should only generate coreboot.rom (why not x230.rom btw?), and no 4mb and 8mb files. (I still don't quite understand their existence presence.)
That 12mb is to be flashed from within heads, preferably with user keys bundled in.
Didn't try to fit whiptail (not FB) in x230-flash.rom and replace the board init script with gui-flash.sh, but if that fits, the UX would be nearly flawless IMHO. The user could then take x230.rom, generate his keys and add them into the rom in one, easy step.
This way, a new user could generate his keys directly from within heads to external storage and integrate them in the reproducible rom to be flashed, without the need of a second computer or an installed OS.