Installing MrChromebox’s firmware requires us to disable FW write protection, whether it’s software or hardware. However, I’m wondering if it’s advisable (or even possible) to re-enable FW write protection after installing the UEFI full-rom firmware, in order to restore Chromebook’s security model?
I understand that the memory map might be different than the one on this page (MrChromebox.tech) so I might have to adjust the write protection range. Has anyone here tried re-enabling their WP?
There is no point when you can just boot any os from usb
Not when secure boot is enabled, I believe. If I understand it correctly, the read-only part of the firmware will serve as the TCB and will verify the read-write portion, which in turn will verify the bootloader, and then the OS. Thus, you can’t just boot any OS from USB without adding its signature first.
My question is more about that read-only part of the firmware. Since all of the firmware is RW, it is less protected in this model. Thus, is there some part of the MrChromebox’s UEFI firmware that could be set as RO?
There is no firmware verification in full rom
But isn’t SecureBoot implemented since 4.20?
That only verifies the os, not the firmware.
As R/O-parts of the firmware are quite typical the basis for a trusted boot process like secure boot (or like verified boot with coreboot, see for GBB at Tianocore/Coreboot docs), is there any progress here? Is verified boot (including the vblock steps) via Mr Chromebooks coreboot and edk2 implementations possible at all?
progress in what sense?
RO/RW via vboot is simply not part of the design.
Some boards may have enough space to do it, most older ones do not - esp not with RO+RW-A/B
But the biggest blocker is vboot - it locks you into a static coreboot version. If one builds/flashes a ROM with vboot, then you are stuck with that coreboot version forever (like Google is), because you can’t have a newer vboot in RW than you have in RO.
I’m new to this community and I’m just here to find out what is possible and what not.
My question here was: has there been any progress to implement something like vboot and to set parts of the firmware read-only?
With progress in the sense of: work done to protect the boot-chain.
Please don’t get me wrong. The work already done in the Community, especially by you, MrChromebox, is absolutely fine and I do not want to persuade anyone to do this work. It’s just a question if anyone already addressed this topic. And the answer “no” is expected and absolutely fine.
This is a community project, the focus currently is on functionality, to get it running on as many systems as possible. And I am very happy that this is done with such a great success currently! Thank you!
Btw. - I think you are wrong with your rating that vboot is a blocker.
Undoubtedly a protected core of the firmware means that this core is not easily upgradeable. But this is reasonable if this core is only responsible for the absolute minimum of functionality, which is needed to fulfill its task to provide a trust anchor and to secure further steps of the boot process. That’s the reason for vboot (Google’s Verified Boot implementation for Coreboot) that - according to vboot - Verified Boot Support — coreboot 25.12-53-gf24a2f35bf documentation - even early stages like romstage, postcar, ramstage, and any further stages are (for the regular boot process) NOT used from the RO-section. For the regular boot process these coreboot parts are easily upgradeable. At least as far as I can see. Correct me if I’m wrong.
Not to have protected Firmware is fine for development. A full read-write stack, including an easily read- and writeable trust anchor, is quite handy for development, and therefore it is mandatory for anyone who is enhancing the core of the firmware. So it is absolutely fine - like I already said - for this project. But it is not the best basis for a secured system.
vboot shares a work buffer between RO and RW. RO fills it with a vb2_shared_data struct during verification. That struct has:
Magic and version (major/minor)
Offsets (e.g. data_key_offset, preamble_offset, hash_offset) into the same buffer
When RW starts, it runs vb2api_reinit() on this buffer. That function enforces:
Magic must match
Version must match: same major, and minor must be ≥ RO’s minor
So RW’s vboot code must expect exactly the same struct layout and version that RO produced. If RO and RW are built from different branches or commits, they’ll have different VB2_SHARED_DATA_VERSION_* constants and/or struct layout. Then RW either fails reinit or misreads the offsets and corrupts verification. That’s why RO and RW must come from the same codebase.
This means that if RO is actually RO, that RW can only be updated so far as there are no changes in the vboot shared data or major/minor versions.
make sense?
Thank you for your detailed answer. Like I said, I’m new to this topic so I need details like these to go further.
Yet I think it’s still not enough information, as I cannot follow your statement that even different branches or commits do change those values. As far as I understand VB2_SHARED_DATA_MAGIC it is not a magic in the sense of for example Linux’ module vermagic, to have a value which differs with every build. It seems to be a fixed constant at the beginning of the struct to detect if the memory at hand is the correct struct type or something was corrupted. The magic seems not to have change since the beginning. Seems to be completely unrelated to this topic.
And the major and minor version numbers here seem not to cohere to coreboot versions. Even completely different coreboot versions may have the same versions for VB2_SHARED_DATA_VERSION_MAJOR/MINOR numbers at least if the layout of the struct did not change, for example because the vboot implementation remains the same or is compatible to each other. Both seem to be change quite seldom. Even the minor version seems to be the same for several years now.
Having coreboot updates of many kinds with ro-sections, even from different code bases, seems to be quite possible at least.
As you are an experienced developer and I don’t think you are mistaking this and I am new to the topic, I think that I do misinterpret this here. Yet I’d like to understand what my misunderstanding is, so please don’t beat me for still asking in this topic. 
saying “it doesn’t change very often” doesn’t negate the fact that it does change, and that adding code to deal with handoffs between differing RO-RW struct versions gets very messy very quickly. It also means that future changes have to be evaluated with the context of how they might break older RO handoffs – something that the vboot project (which is separate from coreboot) has not committed to doing.
This is the exact reason why Google has firmware branches for every device/platform, and why you only see select backports/security fixes to them, rather than using a rolling release based on coreboot main.
4 changes in 6 years, one within the last 4.5 years, does not explain branches for every device/platform. That doesn’t explain per device branches.
It’s more like the old topic of rolling vs. stable releases. Both do have their own reasons and their own use cases. Like with Linux distributions. Even with the presence of Arch Linux the old RHEL still has its use cases. And both do have their own goals. Stability for example. For predictable stability it’s reasonable to have fixed release branches and selected backports mainly for security fixes. And that’s also typically a good reason to have per device branches, even if that means some more work to do. Even the Linux kernel has several longterm branches, despite this is a little against their conviction. Simply because it makes sense for several use cases.
So I don’t think without vboot Google would not split their devices into different branches.
Yet, implementing vboot certainly means additional work to do. Google has security in mind. So they accept the disadvantage of some more work to do for the benefit of advanced security. They do have the needed manpower.
I’m not an experienced developer, so it’s probably above my skills. But, let’s just say, there will be someone willing to experiment with this and tries to implement vboot, maybe later on even including a locked ro-section, for the one or other platform here. Would it be something you’d also support or is it against your conviction and you will torpedo this efforts anyways?
you’d be wrong, look at how google (historically) does software development across their entire ecosystem. everything is built from a branch. This is immaterial to your question about the MrChromebox project using vboot however.
there’s nothing to experiment with, you simply enable vboot via config and (optionally) add your own keys, then flash.
besides the limitations imposed by vboot with a fixed RO, there’s also the additional logistical headaches that come with distributing updates when dealing with devices with mutiple configs (stock Google, MrChromebox w/o vboot, MrChromebox w/vboot, WP enabled, WP disabled, etc). It’s not something that I’m interested in adding to my plate because the disadvantages outweight the advantages by far. If someone wants vboot, they are welcome to fork my project and enable it, and deal with those headaches.
This is the statement I’m referring here and I simply doubt that this is true. Yet, that does not matter regarding vboot within MrChrombox’ firmware, anyway, as long as their main developer(s) think that:
Like already said, as long as you do not have security in mind, this is absolutely reasonable.
And your last answer makes clear that you are not interested in these kind of development. So for me all answers are given.
And like I already admitted, that’s totally fine and I absolutely appreciate your work!
Nevermind.
Btw, the best reason to have a fixed and read-only base part of the firmware, including recovery functionality (like it is done by Google) is definitely not only to have a trust anchor for firmware verification, which is a base requirement for effectively secured devices and essential for verified boot / secure boot.
It is reliability. With a ro/rw-split and updating only part of the firmware (i.e. separating even the RW-part in two redundant sections) millions of devices in millions of different situations are auto-upgradeable without even a chance to brick the device. This way even recovery from power outages while processing a firmware update is easy and can be done fully automatically. That’s a really good reason for mass device manufacturers with warranty promises on their devices.
As far as I know firmware updates for Chromebooks are fully automatic and part of the ChromeOS updates. Do you know of any other device of this kind with automatic firmware updates?
Like I said already, this is something not in the focus currently here in this project, for good reasons! Yet to have RO sections on original ChromeOS devices seems to also have very good reasons.
