'Reasonably Secure Hardware' (Stateless Laptop Progress & More)

The laptop.

Edit: Dag nabbit. I meant the whole laptop with heads + coreboot + neutered ME. Although the nitrokey/libremkey is a sweet addition.

I should have pinged you in my previous post… Qubes certified laptops? Nice! Thanks!

Understand :100:
When first saw

I think NO never not me. Still

If qubes-certified-laptops had been option then I would have taken but learn less.

Today I envy weyoun.six who have heads x230, w530, and t430.

Edit: Credit weyoun.six


Houla. That is a terrifying picture that should be replaced! Can you point to where that image was taken from? It reflects a R&D setup more than a user oriented flashing setup. I can see there a disconnected crumb board (spispy project?), a connected teensy board (an open source hardware flasher project named spiflash from Trammel, also hosted as well on his osresearch github repo). What is shown on screen is also scary for someone just wanting to flash coreboot derivatives and doesn’t represent flashrom’s documented ch341a programmer reality.

People can flash with multiple programmers. A lot of documentation was produced from coreboot derivatives projects to flash with multiple devices following different values (opennness, accessibility, repurposing of already owned raspberry PI) of the authors who wrote the articles. The easiest and most accessible programmer is out of question the ch341a programmer with a SOIC8 clip, which is what is documented under Heads, which is a really good fit for Lenovo laptops.

It should look way more user-friendly. Something like this with documented ch341a programmer (most accessible and low risk approach for Lenovo laptops SPI chips which are tolerating higher voltage range then other capricious SPI chips in other boards):

This is @weyoun.six’s picture! (hopefully, that was ok flagging you!)

Again, as I try to remind everyone each time Heads subject is raised: the Heads documentation should not be scary, it should be accessible. And for that to happen, that documentation should be modified by those who struggled using them for them to be easier to follow.

I would invite everyone to contribute back to GitHub - osresearch/heads-wiki: Documentation for the Heads firmware project in the goal of having https://osresearch.net/ as accessible to all as possible through incremental, community driven improvements!

At the end of the day, the actual certified products today (Lenovo’s x230, t430 laptops) are supposed to be locally accessible machines today, that can be bought refurbished or second hand locally for most to flash themselves with low technical background: Lenovo X230 Maximized - Heads - Wiki

After that, installing Qubes OS on them should be straightforward as well: Step 4 - Installing Qubes and other OSes - Heads - Wiki

Certified Qubes products aims at supporting specific hardware configurations with Qubes OS preinstalled.

The actual models have Heads pre-flashed. There is nothing stopping users replicating those hardware configurations, and to flash Heads on top of them and then installing Qubes themselves.

After all, a side benefit of the Qubes Certification is also to have Qubes OS team test for regressions on those certified hardware models.


yes, this is my heads xx30 family :blush:

my recommendation, if you are uncomfortable with pulling apart a laptop to flash, is to purchase an x230 through Insurgo to support all the work they do for the heads project.

but I would also consider this: if you want to mail me your xx30 thinkpad, i would flash it for you on a sliding scale donation basis. feel free to PM me if interested. i’m also willing to be a resource for people trying to do it themselves. feel free to reach out here or on the heads matrix/slack.



@weyoun.six: Thank you for that! My counter-recommendation here would be to push for better Heads documentation, as a community, so that users can take their own power back and replicate the setup for themselves.

Doing one laptop at a time, I fear, didn’t serve this goal as much as I wanted this to become, and all the supply chain complications (even more since Covid) made me reconsider my own desire to be a hardware+support provider, which I think is more beneficial here (through forum and main documentation improvements) than on a 1:1 basis, for the whole community.

On my side, I slowed production dramatically in the past months, to the point where I am now taking a pause from selling altogether. Doing one laptop at a time is not helping the whole community as I wish it had.

Doing research and development, as you might know, requires concentration, time and energies which I find more productive for the whole community, and doing both at the same time requires additional management toll (supply chain, import, reprogramming, OEM disk image maintainership, flashing, tamper seals, pictures, customer secure communication handling, secret sharing, shipping, support for re-ownership and then one on one support request handling) which is counterproductive for research and development goals.

So my present goal is to go back more into research and development, where doing laptops was initially aimed to funding my research and development efforts. I found that the two are not compatible and that my interest is more into research and development than into providing hardware and direct 1:1 support for users instead of organizations.

The whole goal of Heads and its OEM Factory Reset/Re-Ownership wizard is to provide anti-interdiction mechanisms and in-transit tamper evidence. As a side effect of this, this enables companies like Insurgo/Nitrokey/Purism/Hardenedvault to provide such services as well.

But if a user flashes and installs Qubes OS himself, then there is no need for shipping anti-interdiction mechanisms: the user controls the whole process, where heads offers the same tamper-evidence mechanisms when roaming around; when the device is left unattended, when combined with Glitter - Trammell Hudson's Projects and Blink Comparison | F-Droid - Free and Open Source Android App Repository ideas.

The next goal is to make this easier for all, not just customers. And I hope the actual Heads community and enthusiasts will merge efforts into facilitating accessibility for others, and that is through documentation improvements, on which I will of course participate, just like I do right now, but answering to direct needs instead of reacting to unfulfilled needs.

This is an old dream of mine. I started this in the goal of facilitating decentralized and accessible, reasonably secure hardware. I also made a presentation exactly about that at FOSDEM 2 years ago FOSDEM 2020 - Heads OEM device ownership/reownership : A tamper evident approach to remote integrity attestation. The ideal would be for the hardware to be locally reprogrammed, with shipping being out of the question. Just like people are flashing coreboot as a service around the globe, the ideal would be for local repair shop to offer that as a service. With Heads maximized builds, a user could flash internally a firmware image prior of installing Qubes, making sure that the firmware is trustable, without even having to trust the repair shop which simply “unlocked” the machine to be user-owned.

I personally encourage this kind of offered service @weyoun.six. Buying hardware second hand should be the way to go, with Heads being flashed as a service being the real benefit here. After that, my recommendation as of today is to push for better defaults inside of Qubes OS. Better and easier software installation methods to make Qubes more accessible as well.

But pre-installing Qubes OS like I do, maintaining the OEM disk image and customizations (with/without Windows, with/without signal. Replicate with all softwares possible. People complain when something is there that they didn’t want preinstalled; when it’s not there but would have wanted it…) comes with a lot of liabilities and complications I am not really interested in dealing with anymore. The solution there is to ease those things to the point people are not scared of doing it themselves, following simple documentation, updated upstream. And I prefer orienting my energies into resolving those issues upstream then having to deal with them on a 1:1 basis, with users believing I have to resolve those issues for them/with them.

As of today, I still believe the best is for the user to install Qubes OS himself and understand the process. Otherwise, when comes the time to reinstall (Qubes 4.1 required that), the end user is still scared by the process. And to flash Heads updates (which Qubes 4.1 also required).

The ideal is to have users aware of the backup/restore/update/upgrades processes and be able to do so between Qubes OS releases and templates becoming EOL, otherwise I am not sure of the real benefit of the process other than to be able to ship a laptop internationally, with anti-interdiction mechanisms in place. But there is no need for anti-interdiction if the user can do that himself, or if there are firmware flashing as a service.

I am also convinced that organizations would benefit into flashing those devices themselves for their users, and that would be beneficial to both Qubes OS project and oganization’s users, where the organization is better placed to take a stance on the liabilities involved into choosing to deploy certain software packages and repositories, while also maintaining their own OEM disk images for their users. That was always my goal, and I would definitely would love to participate into those movements more directly, be engaged as a consultant for such organizations.

But I currently doubt that doing one laptop at a time is serving completely its intended purpose and my own. And I hope this reply clarifies my position on the matter. :slight_smile:


Well, that was from HOPE conference, which explains the “hackyness” of the picture. :face_with_spiral_eyes:

Opening an issue for all the images to be changed would be an important step forward. Better would be to replace those images in a GitHub Pull Request!

:confused: Think HOPE image good for threat model section.

What wrong with all the images?

Solomon1732 say don’t desire to learn how to flash BIOS. Try to be helpful and recommend certified laptops.

Major benefit and huge credit to you. Thank you!

Not really complicated. Qubes currently certifies a single other company that sells the same hardware family of Heads supported laptops x230/t430. This is the easy thing to find on Qubes website directly Certified hardware | Qubes OS

Other sellers will come sooner than later. More performant, more recent, but fuller of Intel FSP/ME AMD AGESA/PSP blobs to widen hardware offer on x86, which is the only possible Qubes OS supported architecture for the moment :slight_smile:

Sorry for the sarcasm notes. I really wish the x86 blobs situation changed, but it hasn’t for newer hardware. So the users will need to choose for themselves on what they trust, what blobs they decide to rely on in exchange for newer and more performant hardware, which is the subject of so many other threads on this forum alone.


I don’t mind reading documentation at all. Neither do I mind installing Qubes or any other OS. Flashing BIOS scares me since I can brick my computer – I don’t have money to spare in such a case. I also don’t always notice where I lay my hands or other house utensiles. Therefore I can easily knock something off and screw something. Theoretically, if I could buy flashing as a local service I would – at least the first time

1 Like

Forgot to mention: I do read various documentations from time to time. And I succeeded installing Qubes and a few Linux distros. Hardware? It’s a whole new world.

Nothing wrong with other images, but console access can scare a lot of users, where console access is not needed since a really long while under Heads unless recovery actions are needed. This is more representative of current Heads UX:

This is not Heads related thread though. A lot of other threads exist on the subject. I just wanted to post in that thread that Heads, on non-bootguard locked hardware, is totally possible, where “states” can be measured, where stateless from Johanna’s paper relates more to externalizing the states, which as far as I am aware, had no progress for the moment and where Heads and coreboot’s measured boot (which is what Heads depends and extends) is an interesting alternative to UEFI for coreboot supported platforms. I wish to see more of those, with clearer statements on which blobs are required to initialize and keep functional the platforms in question.


Just posted there to reference here:

1 Like

So much there. How to inform interested users of real choices? You more than doing your part, asking for a friend :grin:

This require much education. Your posts help.

Returning to stateless laptop progress topic, does @pietrushnic saying

still depend on

Presume yes but happy to be confused.

1 Like

Some needed clarifications:


All are deploying Heads or Heads derivatives/forks of Heads.

Pureboot, Vaultboot add some features, such as all forks normally do in the open source world. Forks are a normal outcome (while not always desired) in open source project, being normally the result of needed differences to accomplish different, or specialized, goals.

One embracing the mission of comparing codebases will see differences in “boot policies”, mostly. From the differences in codebase, outside of Heads core changes that have not yet been picked up in the forks today, the interested would see changes that apply to servers more specifically, or to PureOS.

Autoboot from Vaultboot, Restricted mode from Purism. Vaultboot implemented TPM2 support and chipset locking on their supported plarforms. Pureboot implemented root filesystem tamper detection for PureOS. Vaultboot created automatic release of TPM disk encryption key for their server. Vaultboot also deploys authentication to access recovery shell.

Some of those changes were suggested in pull requests, but the user base and use cases being so different didn’t permit generalization and inclusion under Heads codebase directly, Heads not being directly linked to consistent support channels in case of “I lost my USB dongle and now I cannot boot the machine nor go into recovery shell and my machine collects dust, I cannot externally flash my device nor buy a new USB Security dongle…” kinda problems…

Ideally, commonly used code should be merged upstream when goals of projects matches, since this also reduce forks rebasing efforts and also facilitate collaboration upstream. While lowering codebase maintainership costs across forks.

This is true and is HOTP variants of the boards when available. See https://osresearch.net and search for HOTP. Note that you can download firmware images directly and that the process is also documented.

Purism’s contributions to Heads are massive, including an early partnership to have HOTP supported into Heads with their Librem Key (being a fork of the Nitrokey Pro open hardware design), and their efforts to bring whiptail and fbwhiptail (a beautiful graphic alternative (gui-init) that has now replaced original generic-init from early Heads days (that was console based and some documentation artifacts still letting users think that Heads is for experienced users only)).

That’s it for my facts correction on all posts above related to Heads.

To go back on topic: advancements on stateless laptop.

The starting point of this discussion should point to the origin of the idea

Key concepts:

  • minimize firmware
  • centralize firmware (Everything in one flash image)
  • externalize flash to be read from external media

To debate:

  • do we agree that states should be externalized?
  • would we not prefer to have all its firmware parts internally measured and attested?
  • we want an unbootable (brick) platform without externalized firmware available?

I’ll state here the obvious, even though it is tangential. I simply feel it is worth mentioning.

State always exists and has to. Hardware is not a static mathematical starting point and function. Rather it itself is a state; the external world—a stateful world—affects the hardware. Therefore the question becomes “where do we desire state to be?” and “how do we handle it?” I know not the answers for myself, much less for others, and moreso for projects.


I tried to PM you. Message seems to have disappeared.

I am interested in - perhaps - arranging to have an X-230 ROM Flashed. $$$

I seem to have poor vision and fat fingers.

Do you have PM’s blocked?

hi @catacombs , sorry for the lag time. sending you a PM.

@Confused thank you very much and I’m really sorry I’m getting to the topic after a year of break.

I was wrong here KGPE-D16 can easily be trustworthy workstation and AFAIK some community members use it in such way.

Re-upstreaming would be very hard thing. Another series of old AMD platforms was removed from coreboot master branch. I don’t want to go deep into that. KGPE-D16 is still very popular but code quality is very low estimated amount of investment needed to rewrite that code is enormous (some say about couple hundred k).
I expressed my opinion about state of AMD on Phoronix forum and in various other places [1]. All those circumstances make things very complex. We used Immunefi funds to improve state of KGPE-D16 and it is in way better shape than before (AFAIK Leah from libreboot send people asking about KGPE-D16 do 3mdeb and Dasharo, some configurations are definitely more stable than before). Last release notes can be found here

In general there is need for significant change in open-source firmware community otherwise we can forget about our dreams (KGPE-D16 reupstreaming, stateless laptop etc.). I guess @Insurgo or 3mdeb are not build from people who will give up easily.

Unfortunately not for Qubes, yet. This comment was based on observation about evolution of computer architectures. In general ARM had way bigger potential to be more open, they change direction so it is not yet know how it will affect our ecosystem, but I don’t feel anything good from supply chain wars and geopotical crisis.

Xilinx/AMD put some money in Xen to make it work well on ARM, but who knows what will be future of Xen. Let’s be honest without financial involvement from companies it is hard to imagine a lot of major development would happen.

Things may change when ARM laptop, desktop and workstation will reach masses.

No updates, just hope. I will be more specific commenting @Insurgo topics, which try to get back on track with this thread.

I think next stage is ARM, but depending how after MacBook M1 market will look like. I guess policy makers rather killing open-source firmware then making it thrive, but we will see how open would be next mass market ARM laptop. Overall we may came to sad (?) conclusion that Google Chromebooks are most open from high-performing ARM devices.

I would ask this question in different way. After all these years do we see any so wide-spread, accepted and cited paper, which provide alternative approach? AFAIK no. If we can’t create competing strategy or at least create incremental improvement over, then we probably have to agree on de facto standard proposed long time ago by Joanna et al.

I think there is huge potential in Framework hardware or similar modular design. Please note similar strategy was applied by IBM with LibreBMC. What OpenPOWER Foundation did was creation of competition to ASpeed on BMC market. If Framework or other similar company would be able to move whole state to modular component, or maybe to no be greedy at beginning, some part of “the state” to lets say hot-pluggeable BIOS storage it would be move in good direction.

You may think if it is even possible? Yes it is. On COM Express market this is standard feature to not boot from vendor soldered SPI flash, but connect something externally and control that. So it is matter of externalizing SPI bus. Then you just have whole firmware that boots your platform in your pocket. This of course largely improve open-source firmware adoption since hacking means to have two such modules with production and development version of BIOS.

No matter if we externalize things we can employ additional measurement through various means (S-RTM, D-RTM). All together would really give us trustworthy computing.

Or maybe not, we would have another enemy: firmware everywhere and ROMs. Despite that stateless+S-RTM+D-RTM would cover a lot of threat models.

If it is optional, why not. If one don’t like unbootable device, then one should avoid externalization.