I totally agree with the above. The problem here is not the hardware itself, but the requirement of deploying a constant, and supported, hardware configuration (same specs) from the certified hardware reseller for one year. That would probably also have had encouraged firmware development and collaboration to some level, but that would also not be guaranteed.
As per certification requirements, those included hardware lock down and firmware lockdown. this changed since then. This evolved with participants collaborations (the certified hardware resellers and feedback, collaboration) and collateral learnings.
The devil is in the details here, unfortunately. I can only speak for what I know here and not want to blame any party, just trying to recall the facts so that the certification process can continue to evolve, being aware of a lot of new certification hardware that will come, which I really welcome. Diversity is needed. ewer hardware is needed. Others participants, new blood and new participants in the process will make things better. Compliance and collaboration of all partieswill make things better. If collaboration is enforced.
Historically to this point:
- Purism had difficulties deploying Qubes on their machines. Qubes OS+Purism tried to develop an OEM installation media and maintain it conjointly with Qubes to ease unattended installation and failed to do so in the long term. I also recall the certification fees to be too high at that time, being the first certified partners and all of that limited the sustainability and profitability of the partnership, but I am not aware of all the details here.
- Nitrokey took hat unattended OEM installation ball recently, and Purism joined in the effort. This is a separate thing altogether from having some hardware certified. This has to do with facilitating Qubes installation on certified hardware. Without any Qubes customization outside of kickstart selected options. Basically permitting to install Qubes with a hardcoded encryption key passphrase that the user is encouraged to change at hardware reception, relying on external, physical tampering mechanisms (read tamper evident bags) to protect Qubes installation integrity since the encryption key passphrase is known and exposed on their respective github repositories for their kicstart files qubes-oem/ks_template.cfg at 48a2d9dbc2fe792fc5d3fc33dedef470ac8bbd0f · Nitrokey/qubes-oem · GitHub and discharging liability in their Readme: qubes-oem/README.md at main · Nitrokey/qubes-oem · GitHub. But this is a good start: it permits Qubes unattended installation. This is first step. As discussed before, Qubes installation media would benefit having external customization possible (external kickstart source, absorbing salt recipes to be deployed on first boot with network being configured etc, but this is still not existing). Meanwhile, Qubes OS media is modified by resellers.
- Then, the certification process and requirements changed. When Purism first certified their hardware Librem13 which then diverged into Librem13v1/Librem13v2) it was first an Ivy bridge based laptop, this means it could have its ME neutered, which was not the case on Librem13v2, that Librem13 marketing speech was not consistent, made users roar and Qubes support complicated and Heads support request and discussions complicated. Nothing existed in that time saying they were supposed to support a specific hardware certified model for at least a year, and changed their components. Librem 13v1 became v2, and a lot of ink spilled on that matter everywhere on the internet, where some posts can be read on this forum on the matter, even related to Qubes being confortable certifying them again in the future. Have not followed that discussion thread myself. On a firmware perspective, this meant a lot of differences. Its not the same chipsets, not the same ME, not the same anything. This is where the requirement to have a hardware model, with same components and same firmware, was locked to be produced and supported for a year, minimally. This lead to a lot of problems with locking the firmware for next certified model (PrivacyBeast) which needed to be extensively tested, and required a lot of documentation to be produced instead of fixing the firmware itself and providing firmware upgrades to mitigate issues). This requirement on firmware lockdown vanished since then. But the hardware produced (same specs) support of a year (logical) survived. This eased the path for Nitropad certification, which used already existing hardware and existing firmware. Basically making them exactly what you are saying here @unman: Nitropad is basically selling a certified hardware, reusing existing firmware. Just so you know, they basically use the x230 and t430 Heads boards and rebranded them to be Nitropads in their fork.
Some learnings on firmware side of the certification (part I am aware of being firmware maintainer and in Heads development loop):
- Some pureboot (heads fork) firmware update release was produced without measured boot enabled, of course fixed on later release PureBoot Security Flaw for Librem 14 Patched - Hardware - Purism community
- Firmware was flashed without firmware regions being unlocked, limiting user control over their firmware and requiring sellers to offer firmware upgrade as a service Firmware Update v1.4+ - Nitrokey Documentation . This was a side effect of not taking seriously testing of firmware prior of accepting merge upstream under Heads. users/collaborators/contributers are all different participation levels.
- Firmware testing from certified sellers (all Heads based) is not easy to coordinate testing, even today when it comes to regression testing of some features, definitely impacting coreboot/linux version bumps and speed of release. Too many forks, not enough upstream collaboration.
From all this learning, my take is to be an upstream contributor as much as possible and I encourage others to take that path as much as possible.
Same applying to cacher, whonix, Heads, coreboot, flashrom, kexe, cryptsetup etc, obtaining/pushing others to get grants applications, obtaining funds to further develop tools we all need, (coreboot, linux, heads, wyng, cacher, remote support tooling) and promoting those projects so they evolve with the passion of their contributors.
For the sole Qubes scope, extending to all its dependencies, it means collaborating and contributing with Qubes developers as much as possible.
On Heads, this means exactly the same. It all depends if we are simply users, collaborators or contributors of such projects, if we want the whole ecosystems we are using to evolve.
Or… If making profits on such ecosystems is enough. Of course profit is needed for each of those projects to survive. But for such projects to not only survive but thrive, this needs knowledgeable people to contribute back. All of those are open source projects. And can evolve only if such contributions back exist.
In the current case: this means support related to Qubes to be under Qubes if beneficial to the whole ecosystem. That is my opinion, and this is why the OP post was created.
Assigning all PCI devices to sys-net will always be a bad idea. Having a way to boot the system into a live system is needed. And this is why I created this post.
Aho.