Can you set a BIOS password?


Hi all,

I’m a new Librem user. I have a few questions I can’t find the answers to.

(1) how do you access BIOS?
(2) can you set a BIOS password?
(3) can you password protect booting from a different device (pressing ESC on purism boot screen).

Thanks in advance,

  1. there’s no user-facing settings to access, only the boot menu (and TPM submenu)
  2. not applicable
  3. not currently

setting a password to restrict boot device access would require a mechanism to read and write to the SPI flash, which SeaBIOS doesn’t currently support (as well as user-facing controls). There’s no technical restriction on doing so, but our engineering resources are currently focused on migrating away from SeaBIOS and to HEADS as the payload of choice


@MrChromebox Thank you for the quick response.

Assume an Evil Made gets access to my laptop. Because I cannot password protect the boot menu, they can then boot to a DVD of their choosing and load an operating system under their control.

What’s to stop them from injecting malware into device firmware in order to install an APT? Perhaps this is a silly question, but I’ve heard too many war stories about APTs on wifi cards, etc.


@ceretullis this is exactly what HEADS is designed to protect against, and why we’re focusing on that. Even with a BIOS password, you can’t be sure the firmware hasn’t been tampered with if an attacker has gained physical access. HEADS (with a Librem key) will.

If you have a Librem key and want to check it out, see:


@MrChromebox from previous discussions I found on the forum it wasn’t clear to me the intention was to use HEADS to validate the firmware on every chip on the motherboard. If the intention is in fact to validate the firmware of every chip on the motherboard before booting, I’ll be a very happy customer - can you confirm that’s the case?

Any idea when HEADS will ship? Will it require a Librem Key?


@ceretullis not sure what you mean by “validate the firmware on every chip on the motherboard” since that’s not really practical. HEADS will validate the main/system/AP firmware only, though I’m not sure what other firmware you’re referring to specifically (maybe EC?).

I don’t have a timetable for HEADS being released, either as the default payload on new devices or as an update for existing owners. It will almost certainly require a Librem key


@MrChromebox I’m thinking of this mostly from a theoretical perspective and I’ll outline my thinking below. Perhaps my line of thinking does not line up with the reality of the situation, in which case please say so and to what extent.

Let’s say each Librem motherboard has a set of chips C and a set of peripherals P attached. Let’s say peripherals have access to some kind of bus in this case. Let’s say there is a subset chips in C which have some persistent memory that can be flashed, let’s call this subset Cf. Let’s say there is a subset of peripherals which have some persistent memory that can be flashed, let’s call this subset Pf. NOTE: I’m not going to distinguish between chips which can be flashed from software, which I would consider more critical, than those which require physical access and a dongle because I believe HEADS should protect against Evil Maid attacks where the attacker has physical access to the machine.

Let’s say the persistent memories on these chips and peripherals hold some code or information which is used to operate the chip/peripheral. And let’s call this code or data “firmware” for brevity.

In my line of thinking, HEADS needs to calculate cryptographic hashes for all of the chips in Cf and all of the peripherals in Pf during the boot process and validate them against known good values.

Failing to do so, means there is a theoretical probability the skipped chips or peripherals could be used to store APTs.

Obviously, there is a game theory angle here by which using HEADS to validate any subset of Cf and/or Pf represents an iterative improvement over the current state of affairs - and I applaud Purism for pursuing this technology because of this angle…

… but … the more of Cf and Pf covered by HEADS the better I’ll sleep =)

Comments and corrections appreciated.


@ceretullis you left out two important variables/sets – the subset of chips or peripherals with firmware which can be read by HEADS, and the subset for which there is a known good cryptographic hash of a particular firmware version which HEADS could validate. I’m guessing the intersection of those two sets is close to zero, if not actually zero.


Yes, you make a good point about the possibility there are chips or peripherals HEADS can’t read. And I was also assuming, perhaps incorrectly, if you could flash the firmware you should be able to read it. I didn’t think about the possibility HEADS might not be able to read firmware from some things in Cf and Pf.

In the ideal world, if HEADS can’t read the firmware for some chip or peripheral you could mitigate this by ensuring those chips or peripherals did not have flash-able firmware. Is that practical though?

With regard to known good hashes, I probably should have laid out my definition for that. I can see how some people would insist on knowing the providence of the firmware from source code to machine code to hash. And sure, if you’re manufacturing everything in-house, that could be done, but that’s not practical. Therefore, end-to-end providence isn’t practical in my opinion. Then, I would limit the definition of known good hash to mean when Purism receives chips/peripherals, you calculate the hash after assembling the laptops. Then at least customers would know if something changed since Purism put things together - which is what is important to me.

I can understand there must be some real challenges even with this approach when considering the manufacturing world. I imagine Purism is not always notified of changes in chips/peripherals. I guess if it were me, I would try hard to mitigate this with SLAs in supply contracts.