User-flashable coreboot vs "CHIPSEC" security test cases

pva · November 17, 2017, 5:19pm

I found blogpost that reports that Purism Librem15 fails CHIPSEC security tests:

Is this a known issue? Is this dangerous?

Dwaff · November 17, 2017, 5:45pm

Those errors and warnings all complain about your ability to flash bios or write cmos. In case OS is compromised rootkits could utilize this. I wouldn’t worry much about it.

bios_wp:

SMM BIOS write protection is not correctly used
Flash protected ranges do not protect bios region
Root certificate
UEFI NVRAM is not write protected

ia32cfg:

Architectural features not locked

spi_desc:

SPI flash descriptor is not protected

rtclock:

Critical configuration is stored in unprotected CMOS

source about chipsec stuff: https://github.com/chipsec/chipsec/wiki/Vulnerabilities-and-CHIPSEC-Modules

kakaroto · November 17, 2017, 7:08pm

Thanks @dwaff for answering.
Yes, that chipsec security test is recommended by the UEFI forum as stated in the article, and we all know how crazy UEFI is. The bios_wp one literally would prevent you from updating your BIOS. It says “protect” but it really means “lock down”. Personally, I see it just like saying “this laptop is not secure because the hard drive is not ‘write protected’ and someone could install a virus on your system, so they must make the hard drive read-only and only ever run all software from a live image”. or some such nonsense. I think giving the freedom to the user here is important, and there are ways to prevent evil maid kind of attacks. The spi_desc ‘error’ is the exact same thing but it’s about the SPI flash descriptor instead of the BIOS region, just different areas of the same flash chip.

The rtclock is considered a warning because they can’t determine that the CMOS is write protected… well, there are no CMOS on the machine, so that’s irrelevant. The ia32cfg is literally about “locking down” architectural features. Coreboot simply doesn’t work that way. For example, the virtualization is not locked down, so when you open your virtual machine software, it will see that virtualization is not enabled, so it will enable it, and then run the virtual machines. If the feature was locked, then virtualization wouldn’t work, you would need to go into your BIOS, then enable the option, and on reboot, it would enable it then lock down the feature. Coreboot doesn’t work this way because coreboot initializes only the required hardware, then leaves the rest unlocked so it can be enabled/disabled at runtime. Besides, there is no BIOS configuration menu in coreboot for you to go enable/disable features such as virtuatlization.

Anyways, that’s just my personal ramblings on the subject. I hear there’s about to be an official statement in response to that since you’re not the first one to ask the question after that article appeared.

Alex · November 17, 2017, 7:25pm

Lol, talk about making your device useless for anything but browsing.

I don’t see why anyone would want that unless they were literally Edward Snowden.

I certainly don’t want it because it’d make my computer a heck of a lot less useful. And wouldn’t you get most of the benefit of doing all of that by just using Tails? IIRC it doesn’t allow the saving of local files and what-not. I’m sure very sophisticated viruses could do something if you introduced them directly via USB or something, but I figure Tails and Qubes are generally be enough for the paranoid even without hardware-level read-only nonsense.

I love to increase the security of my system, but not looking to make it literally read-only. Maybe one day I’ll make a computer like that just for browsing the net, but right now, no. Stuff like the TPM you’ve added seems like a nice upgrade to security at a hardware-level without having to go to crippling extremes though.

pva · November 17, 2017, 7:43pm

Guys, thank for your answers. I’m not sure I understand your reasoning. We don’t need to update BIOS during normal work with computer. I’ve updated BIOS more then year ago and there was not such need since that time. So why do I need to keep this areas RW for the whole year, while it’s perfectly sane to keep them RO? Probably it’s good idea to have BIOS option to enable/disable write mode for BIOS. Or what do I miss?

Alex · November 17, 2017, 7:46pm

Well for one, I think they just like to leave it so that the user can change things however they want. If they lock everything down that kinda goes against that idea. It increases security at the cost of freedom.

Second, Purism does updates to BIOS-level stuff fairly often as they continue work on freeing the ME and a blobless Coreboot etc since they haven’t completed their roadmap yet - you want to be able to apply those updates without having to buy a new computer or something, right?

I’ll let them answer better though, I don’t work there and this is just my general layman understanding of it.

ruff · November 17, 2017, 8:45pm

I appreciate the freedom, but that’s freedom to the software (and malware), not freedom to the user. As a user I’d want to have freedom of choice. Here i don’t see how I can choose. You can tell me - don’t run virtualisation. Heck, maybe I don’t, maybe i run some software which claims to be calculator but which tries to spin-off a vm

Alex · November 17, 2017, 9:17pm

Ha, isn’t that even better Kakaroto? Better to not have any unnecessary things exist to begin with, reduces the amount of surface area for a potential attack.

Okay, so I’ve never actually used Coreboot before. So there’s no way to access a BIOS menu to change the boot sequence (boot from USB) or set a machine password etc?

kakaroto · November 17, 2017, 9:48pm

You misunderstood. The chipsec security test is only about making the BIOS read-only. My example about making the hard drive read only is just me making an analogy and pushing the idea further, saying that “sure, read-only is more secure, but it limits freedom as well”.

If the BIOS was read-only, then those who had an older librem with AMI BIOS wouldn’t have been able to update it to coreboot, then we wouldn’t have been able to update to a neutralized ME, then we wouldn’t have been able to update to a disable ME, and we’ll soon release an update to add IOMMU support to allow Qubes 4.x to work on the Librem as well. So being able to do BIOS updates is useful.

No, there is no such thing. The BIOS boots into your machine in roughly 450 milliseconds, there is no support for a menu, there is no time even for the user to press a key on the keyboard to enter a menu. The idea of coreboot is to do the minimum hardware initialization and then go to a payload. In our case, we use SeaBIOS which itself will initialize the video card and show the splash screen logo, and wait for 2 seconds for you to press ESC to show you the boot menu and let you choose your device (otherwise, it just boots to the default one). The boot choice isn’t saved, it’s just a boot override. If you want to change an option in coreboot, you need to change the config in the source and recompile coreboot then reflash it. If you want to change the boot order, you need to change the boot order in a file embeded in the flash, then reflash the BIOS.

kakaroto · November 17, 2017, 9:52pm

You are free to run a ‘wrmsr’ command at boot that locks down all of those features

pva · November 18, 2017, 6:50am

Thank you for clarification! But after it boots does it have any kind of runtime? Is it possible to create some kind of bios system call, password protected, to enable/disable write protection?

kakaroto · November 18, 2017, 7:44am

no, it doesn’t have any runtime. The write protection is a bit in the flash descriptor which prevents write access directly by the PCH (https://en.wikipedia.org/wiki/Platform_Controller_Hub), so the hardware SPI controller on the motherboard is the one preventing write access. The only way to write to it then is to open the hardware and use a hardware flasher and SOIC clips (like this: https://www.reveltronics.com/images/stories/virtuemart/product/soic-8_clips_150mils_2.jpg).
So yeah, even if we enable the write protect, it won’t protect against an evil maid with a screwdriver. However, having measured boot with a TPM would protect against it, which is what we’re working on (announced yesterday : https://puri.sm/posts/tpm-addon-for-librem-laptops/).

ruff · November 18, 2017, 7:57am

Does it mean the only choice it offers me is everything or nothing? Or i can apply a bitmask at boot to selectively flip-flop some features?

Alex · November 19, 2017, 4:06pm

Oh yeah, I knew you were using some hyperbole there. My response was sort of jabbing at the hyperbole.

That being said, yeah excuse me asking dumb questions once in a while - I admit that when you start talking about BIOS and chipset level stuff you start to exit my area of understanding just because I’ve never messed with that stuff. Thus my understanding is just abstract and generalistic. I feel like when it comes to computers I’m more of a “General Practitioner” and when it comes to subjects such as this I’d be referring my patients to specialists that live and breathe this stuff like yourselves.

All in all, I think “locking the BIOS” would be a good idea to implement as an optional feature after you complete work on making it blobless / totally freed. Some of us don’t ever mess with the BIOS (me) and don’t really need the ability to write to them in any way.

Though I’m unsure if you’d ever feel comfortable doing that anyway just because you may want to release an update later on for whatever reasons.

I figure if the end user wanted to go even further and create a Linux distro in a hard drive and then make the hard drive read-only, I’m sure there’s a way to do that.

It actually sounds like a good idea if you have another computer for doing work that needs writing. If I had money laying around to have extra computers like that I’d probably opt to have a read-only laptop just for browsing. I’d have to keep my password database on a small external storage just because I need to edit it sometimes, but that’s about it.

kakaroto · November 20, 2017, 7:42pm

I’m not really sure, but I think it might be possible to lock the flash at boot, and the UEFI BIOS is expected to do that. So you can enter the BIOS, flash your ROM to update it using some UEFI tool, but once you boot, it’s locked (I’m just assuming, I’m not sure). This of course is impossible to achieve with coreboot because there is no menu in coreboot, no tools to run within the bios, or anything like that.

Well, there are two things here to answer. First, deblobbing it completely could take years to achieve. The second thing is that there are better methods to protect the flash, such as measured boot with TPM+Heads for example, which is the avenue we’re exploring.