Ability to disable "SPI PR0 platform lockdown call" - SPI write protection from OS' flashrom

[fhvyhjriur]

I tried out current heads-maximized version on a Thinkpad X230. I like to flash with flashrom an other image, but this ability seem to be gone because now there is a SPI PRO lockdown call i can see in the logfiles.

It looks in the logfiles like when heads boot a OS, it enables this SPI lockdown. From the security point of view this is great functionality to have that was missing last time i tried out heads.
But now i cant flash own compiled coreboot images with flashrom like it was possible before.
I took a look a look at the FAQ https://osresearch.net/Updating#internal-flashing
I am not able to find information how to disable this SPI PRO lockdown call to flash with flashrom my own compiled images that are not maximized-images (i use "--image bios").

[tlaurion]

I am not able to find information how to disable this SPI PRO lockdown call to flash with flashrom my own compiled images that are not maximized-images (i use "--image bios").

@fhvyhjriur The Platform Locking PR0 (PR "zero") is enabled from Heads just before booting the final OS, preventing the OS from being able to write into SPI flash.

This means that Heads is considered the only "internal flasher" (through GUI/recovery shell) unless deactivated through configuration options for a single boot so the final OS can write to flash.

The idea with Heads with its internal flasher comes with its included tooling.
This means that today, without deactivating PR0 locking to flash from final OS, you can go in the recovery shell and use flashrom -p internal -w --image bios from there, as long as you also called mount-usb prior to have your firmware image available from that USB thumb drive.

Otherwise, if you really want to do that from final OS, requiring the OS to be booted with iomem=relaxed etc, you can deactivate the functionality for a single boot by GUI, as documented on the Pull request #1373 (comment)

[tlaurion]

Crosslinked #1373 here for consistency and modified its OP post to point to screenshots showing UX to deactivate this if needed for single boot session.

@fhvyhjriur closing this issue. Feel free to tag me if you disagree with the decision "closed as completed"

If this is considered a documentation issue, feel free to propose improvements instead as a PR against heads-wiki project. Thank you.

[fhvyhjriur]

Thanks for showing me the ability to disable it like show in the pictures here #1373 (comment)
I tried this on two different x230 and disabling it worked fine on both.
On the second x230 i had a issue where flashrom inside heads when saving the changed configuration stayed endless at 0%. Because of my experience how long this in general take to flash it, i knew after 10 minutes, that it have to have finished if it even started. After force turning it off, spi write protection in the OS was disabled.

Could you link #1373 (comment) somewhere on the website here? https://osresearch.net/Updating
I expect if i was not able to find the option that easy, maybe also other would miss it and search for it in the wiki on the website.

[tlaurion]

On the second x230 i had a issue where flashrom inside heads when saving the changed configuration stayed endless at 0%

@fhvyhjriur ppease open seperately issues. Merged pull requests/closed issues are not the place to discuss issues or requests. Each things needing tracking should be seperated.

If it's documentation related, it should be under heads-wiki.

It should not be my burden to find things under closed pr/issues. If you are interested into a different outcome, you should be interested enough toake your issue visible and trackable to have a chance of being tackled in time.

I opened #1665

I leave you with opening a documentation related issue under heads-wiki, or better, a pull request to fix the documentation with your own or the provided screenshot.

Makes sense?