Best Owner-Controlled Qubes Secure Motherboard Recommendations

Here in 2025, I am now designing the build for a new high security focused system, and so I’m seeking recommendations for owner-controlled secure motherboards (whether it be consumer, workstation, or server models) that work with Qubes OS.

I have been out of the market for the last ~4 years, so I’m not fully up to date on knowing the present state of owner-controlled systems available, and am therefore seeking to receive thoughtful education, tips, recommendations, etc.

Here’s what I’m aware of being available from from the past:

• Pre-ME Intel Systems
• Pre-PSP AMD Systems (Fam15, KGPE-D16, etc)
• ME-Neutered Intel Systems (me_cleaner through Intel 11th gen)
• ME-Disabled Intel Systems (creepy NSA HAP bit reliance)
• Raptor Talos II (however, not Qubes compatible)

Are there any other options known, more recent or otherwise? Or has the state of owner-controlled secure systems just gotten worse and more closed off?

Desired criteria:

• Required to support open source firmware (coreboot, etc).
• Required to support working HVM & IOMMU for secure sys-net & sys-usb qubes.
• Ideally no ME/PSP present, but fully neutered may be ok.

I would just go with the KGPE-D16, but sadly found out that the somewhat recent speculative execution vulnerability microcode patches have rendered the Qubes HVM compatibility non-working for secure sys-net & sys-usb qubes, allowing only the insecure Qubes PV mode for PCI device passthrough (see forum post #31575 & GitHub issue #9150).

I see that 3MDEB has come along with Dasharo, but since dropping the KGPE-D16, seems to be focused on systems that lack true owner-control, by seemingly offering an open “wrapper” style firmware around the motherboard blobs with having to trust the effectiveness of setting a HAP bit to request the Intel Management Engine be and stay disabled?

Is the following state of owner-controlled Qubes systems sadly true or am I missing something?

Currently Understood State of Owner-Controlled Qubes Security (please correct me if I am wrong):

• Old Pre-ME Intel Systems still would seem to securely work with Qubes.

• Old Pre-PSP AMD Systems do not seem to work with secure Qubes HVM passthrough anymore (not sure if all Fam15 are non-working or just some like KGPE-D16 are non-working?).

• Old ME-Neutered (me_cleaner through 11th gen) Intel Systems still would seem to securely work with Qubes, but not as ideal as having no ME/PSP present at all.

• Recent ME-Disabled (creepy NSA HAP bit) Intel Systems securely work with Qubes but not fully trustworthy/owner-controlled, as the ME/PSP code is still not neutered and HAP bit may not be fully effective.

• Raptor Talos II is best owner-controlled hardware, but sadly still not compatible with Qubes.

Got any insights or recommendations on selecting an owner-controlled secure motherboard for Qubes OS in 2025?

Yes, in addition to this:

Only if you are willing to port Qubes OS to POWER9.

Just found this message, and to some extent, my eyes are bleeding reading this, but on the other hand, I agree.

I think we had a lot of discussions in the Dasharo Community about the future of computing and the trustworthiness of modern computing. Please note that some Ph. D-level experts suggest it is a Linux fault I lean towards that.

I respectfully disagree Dasharo is only “open ‘wrapper’ style firmware around the motherboard blobs” it seem to be taken from narration of Philipp. We aim for trustworthiness and user-controlled RoT/CoT. Saying that just downplaying someone who trying to do something decreasing volume and loosing the game. If we can find critical mass for OSHW and FOSS from boot ROM to application level three will be vendor who will find the way to take that margin. Dasharo Team which is part of 3mdeb at least trying to change something. Either we will fail providing important historical lesson for future generations either we succeed providing better lesson.

So what we have:

• x86 considered harmful - there are ways to improve its trustworthiness and deliver user-controlled root of trust and chain of trust, we made the first step for Novacustom, but be careful what you wish for in place of user-controlled RoT/CoT, because it would be costly for us to manage, such a service can cost a significant part of the whole hardware setup, so we should ask ourselves if we can pay double the price of hardware for such feature (business model is in progress, so this is not something set in stone), there are options to decrease TCB, some work sponsored by OSFF to Daniel Maslowski may help, there is also AMD OpenSIL coming for which TCB would be really small. I can talk about more stuff here to prove we have ideas
• arm - yes, Arm era is coming, what I tried to signal here, there are so many issues with this ecosystem, but user-controlled RoT/CoT should be possible, we are working on some very tiny and simple solution for that, unfortunately, no Qubes OS yet for Arm, but I think we will get there, we also tried explain landscape of user-controlled Arm during FOSDEM’21 and FOSDEM’23, we consider applying with update in 2026
• POWER - there was hope with Talos, but again, how much we would pay for that, we also explain trustworthiness and user controllability for Talos II systems on multiple occasions, it has an old BMC, probably vulnerable, no ability to have a user controller RoT/CoT on that BMC, there are also some unfulfilled promises of POWER which were communicated at multiple occasions by us here, here and here
• RISC-V - I think we are with RISC-V at stage we were with arm in 2019 and I don’t think RISC-V has enough gas to accelerate with the same pace, so I would wait 6+ years

Anything I’m missing?

Regarding legacy hardware and user controller RoT/CoT, I tried to communicate our vision during QOSS’25. In the presentation I also mention old/ancient/historical artifacts and it should be clear that being in the business of maintaining museal artifacts (KGPE-D16 for example) is not easy task, those skills hardly overlap with embedded firmware products development, so 3mdeb is not good at this and investing in that space is just pure waste of resources. We thought differently, we were wrong. Not saying that microarchitecural vulnerabilities and lack of long term maintenance by vendors (not microcode updates) disqualify those old platforms. I would also argue that KGPE-D16 lacked true ownership, because of no means for user-controlled RoT.

One of the fundamental misunderstanding is false perception that everyone needs user-controlled hardware and it would be no brainer to buy user-controlled hardware. I hope in 2-3 years we can get back to this thread and discuss how 3mdeb experiements in this field look like and what was proven.

When you are referring to user-controlled RoT, do you mean a user enrolling their own Intel Boot Guard keys, or are you referring to a Dasharo Heads implementation instead? Any chance you already have a ballpark price quote of the service cost for an end-user to consider?

Well, notice:

https://www.dangerousprototypes.com/docs/Lenovo_G505S_hacking

Older computer.

Which mentions something about building a core Boot for a Motherboard for a tower.

Also, there used to be a few small Lenovo desktops that are similar to an Lenovo X-230. Guessing the Coreboot Flash would work on that MOBO, but one must have a serial port keyboard, serial port mouse. and one must realize that Intel does not provide Security micro code updates for the third Generation.

Hi, I have spent quite a bit of time on this. I recommend going through the coreboot site and seeing what others are doing. I have tried to build my own coreboot builds for unsupported mbs, the ASRock H110M-DVS rev.3, Asrock H110 Pro BTC+ and Macbook pro 11,3.
the Asrock H110M-DVS rev.2 worked, I could wipe the ME on the Macbook pro and it still worked but I am still working on the MB, which should theoretically work. I just haven’t had the time.
You could get Coffeelake working on the Asrock H110M-DVS rev.2 without much effort.
Then you would have max 32GB RAM and imo would be one of the best DIY systems with full coreboot firmware.
I also got the Asrock H110 Pro BTC+ to work (so far) flawlessly with everything, (which is an interesting MB given its flexibility) with an i7-7700K (Kaby Lake).

It is currently running with multiple Ethernet adapters (given its 12 x PCI Express 2.0 x1 Slots).

Here was our work. It is another forum so forgive me in advance if I am breaking any rules here.
ASRock H110M-DVS rev 3.0 and rev 2.0 and me_cleaner

Post by david » Sat Aug 30, 2025 8:02 am

(You would need a SOIC8 (imo pomona is best) clip and a programmer like a ch341a or R-pi)

Yes. Intel Boot Guard is a Static Root of Trust for Verification and Measurement on Intel platforms. We believe users should have the ability to fuse their own keys, but that is not a simple thing.

We believe that the creation of central points of failure is one of the key obstacles to user-controlled hardware and the first step on the way to a reasonably trustworthy ecosystem.

Some requirements that come to my mind for a person who would like to pursue user-controlled RoT/CoT:

• knowledge and skill in managing cryptographic material, and a very likely understanding of key concepts in manifests
• accept the risk of shipping unfused hardware, which can be circumvented on the way
• willingness and ability to perform coordinated deployment with the service provider in a fixed time frame
• acceptance of service provider SLA
• tooling and skill for recovery - it should not be needed, but unless the model is exercised in many cases, it would not be hardened, and corner cases may happen, this implies also acceptance that the target device may be unavailable in rare instances, so assumed hardware availability should not be 99%
• acceptance of the inability to transfer ownership ever - there are some corner cases, if the second owner could be determined before fusing, but that would have to be exercised
• acceptance that losing the key means the hardware is security-wise useless
• user-controlled build ecosystem maintenance, which involves understanding not only the base framework but all binary blobs that are required, the number of which grows with every new microarchitecture
• acceptance that any divergence from approved HCLs and the validated code base will require additional resources to get support from the service provider.
• If we use our RoT, then also CoT should be owned by the user, so this extends skills to need to maintain all CoT technologies used (verified boot, CBFS_VERIFICATION, heads, UEFI Secure Boot, etc.).

There are more things, but I think this is enough to give some perspective.

That all has to be addressed by a correct ToS/EULA or similar legal documents, systems, scripts, tooling, and service provider employee training. Pricing has to be sound to cover all costs and potentially render some margin for growth and open ecosystem contribution. Not saying what kind of experiment it would be for the service provider.

Dasharo (coreboot+Heads) is an entirely different topic here. It is more of a chain of trust solution with its own issues.

I think I gave an unambiguous indication:

Is KGPE-D16 and Opteron still supported with Qubes 4.2 and ideally Qubes 4.3 ?

Not without disabling mitigations that have severe security consequences.

There are issues with AMD chips from my research, the Qubes team still recommends Intel
(Correct me if I wrong?)

What about support for Opteron with 32nm in Xen like Opteron 6230

https://freundschafter.com/amd-processors-without-amd-psp-secure-technology/

@Tonux @pietrushnic @mike_banon

This is not true anymore!

From https://www.phoronix.com/news/15h-org-AMD-Firmware

We can read (see bold text) :

• Bug-free RAM init. Every memory module I’ve tested works. The maximum RAM is now 512 GB.
• Fast and reliable boots. The platform boots consistently and within ~15 seconds for a 256GB setup.
• Native fan control using the motherboard’s hardware monitor
• Thermal throttling to protect the CPU from overheating (and thermal shutdown support)
• Improved multicore performance
• Reduced idle power usage
• Bug-free IOMMU support (tested on Debian, FreeBSD, Xen, and QubesOS)
• Full support for AMDs speculative execution patches, which did not work on ASUS BIOS or Raptor Engineering’s port. This enables the latest QubesOS to run without any problems
• Support for up to 4 PCIe devices, 1 PIKE card, and 1 PCI device (6 card maximum)

Wow, this would be great news for the owner-controlled & secure KGPE-D16, if the Qubes/Xen HVM compatability issue is now resolved.

Has anyone tested HVM-based sys-net/sys-usb qubes on the D16 using the newly released coreboot-15h from 15h.org?

I see the Qubes OS page on 15h.org hasn’t yet changed since 4 March 2025, which describes the insecure PV-based domain workaround for sys-net/sys-usb. But not sure if that page’s information is still correct, or if HVM-based sys-net/sys-usb qubes have been fixed now?

https://15h.org/index.php/Qubes_OS

I have a decommissioned D16 sitting around that I can test, in maybe the next couple weeks, but thought others might get to testing this D16 HVM issue sooner here with Mike’s updated D16 coreboot.

Great to see the 15h.org website (big thanks @Dodoid) and the firmware development work of @mrothfuss (big thanks mike) getting some publicity! Watching your excellent work evolve closely on 15h.org. Also happy to read that @mike_banon is investing serious effort into the KGPE-D16 as well!

Hopefully we can soon confirm that the secure, normal, HVM-based sys-net/sys-usb qubes have been fixed now on the D16.

Interesting. Thanks for posting @James369.

That ASRock H110 Pro BTC+ board with 12 PCIe slots looks quite interesting for plugging in several ethernet cards. Haven’t seen boards with that many PCIe slots before and wonder what kind of cases support such closely positioned PCIe slots.

Wanted to self-correct/self-mitigate these previous quotes of mine…

I’m not sure if such old Intel motherboards & processors can be run securely or not.

Not sure if speculative execution patches made it to these.

I tend to not to want to trust such these boards, nor Intel, especially since prior NSA HAP bit discovery, and recent US Gov acquisition of Intel ownership.

Greetings. That 15h.org Qubes_OS page relates to the old coreboot by Raptor Engineering. I’ve added a note to that page.

Has anyone tested HVM-based sys-net/sys-usb qubes on the D16 using the newly released coreboot-15h from 15h.org?

A 15h.org contributor (rane) tested the latest QubesOS, everything worked with standard configuration. If HVM is default, they are working now. I’ll try to get more information.

@pietrushnic

Sorry to make your eyes bleed. This tech is getting powerful.

My focus was on speaking from my position as a Qubes OS hardware consumer, as in “What can I reasonably buy in the present or near-term for Qubes OS, which I can have secure control over?”.

My perspective is:

• Trustworthiness and Owner Control of machine is not achievable with active ME/PSP running, period.

• Binary Blobs (and maybe hardware parts) of ME/PSP may have almost full power over the system to inspect, inject, or modify the machine’s data/networking/processing/etc.

• There are shady dark patterns of government influence surrounding this matter (e.g. NSA HAP Bit; US Gov Intel Ownership; etc), so vendor intentions look horribly suspicious and bad.

• Therefore, getting rid of ME/PSP is of prime importance to the hardware owner/user in having trustworthy control over their machine.

• I’m not an expert on RoT/CoT, but thought such measures only verified the integrity of what state is booted up on the system, and not what happens while running the system?

• If RoT/CoT trustworthiness cannot prevent run-time attack after boot, then it is only a partial measure (though I agree still an important security measure to pursue), as an ME/PSP backdoor being remotely triggered/executed after boot, during run-time, will still compromise the entire system for that session and it did not matter if the state was untampered with at that session’s initial boot-time.

• KGPE-D16 while certainly not perfect, nor as good as Talos II hardware (or better in future), can still run Qubes OS (combination of trustworthy HW + trustworthy FW + trustworthy OS is key), and D16 is reasonably affordable, especially when buying several machines.

• Can’t KGPE-D16 owners ensure same/similar effect as RoT/CoT trustworthiness by taking measures such as: 1) Reflashing clean firmware before each boot or using read-only firmware chip adapter (like 3MDEB once sold); and also 2) Run Heads for OS/Dom0 tampering detection or use read-only OS/Dom0 media to ensure clean OS state?

• I understand there are potential opportunities for other components/firmwares in the system to compromise state, like @rootkovska identified in her “Stateless Laptop” presentation, but ME/PSP is a central problem to trustworthiness/security that even looks intentionally evil.

• I understand that some people’s threat model and personal values might not require true trustworthiness at the ME/PSP level, but if all things were equal (price, speed, compatibility, features, etc), and people could buy the same modern hardware either: 1) WITH Potential US Government Backdoor; or 2) WITHOUT Potential US Government Backdoor, then I think 99+% of individuals and organizations throughout the world would consier it a no-brainer to not choose any potential government or vendor backdoors in their machines/devices. Many don’t even know about the problem, nor that there are any alternatives. And there has been a noticeable shift in the coreboot industry focus away from the ME/PSP/Blobs owner-control issue, which is disappointing, but technologically understandable due to reliance upon big business chipmakers and legacy software platforms. But giving up control over the trustworthiness of one’s system to intel-inside-secret-spyware-blobs is virtually never a “good” thing for the end-user’s life.

I am happy to see good folks like 3MDEB pushing the relative-trustworthiness of current systems forward. That is still a good thing in the world. And I know 3MDEB and others would also ideally love and jump at the chance to make 100% fully open hardware/firmware systems that are modern and can have a sustainable business model, if such a modern product became possible in the future. Looking forward to watching 3MDEB & Dasharo closely throughout the future to see what innovations might come from them and how they compare in trustworthiness to available alternatives.

But the fundamentally untrustworthiness of recent x86 HW/FW, mainly due to ME/PSP, is a deal-breaker for what I am looking for here.

Great to see that the hard firmware dev work of one person, Mike Rothfuss (mrothfuss), is paying off in reviving the stability, security, and usefulness of the KGPE-D16 and other Fam15h boards, via 15h.org!

I’m happy to be corrected on anything that I’ve gotten incorrect.

Cheers!

@justmike80386

Very Awesome to see the KGPE-D16 being restored to full strength at 15h.org!

Amazing work. Thanks Mike!

Check out this awesome resource: Dodoid’s Computing Freedom Table (DCFT)

Presents a nice colorized table of data showing the freedom vs proprietary/blob status of many specific components that make up relevant Server/Workstation models (5 currently, such as KGPE-D16 etc), Laptop modles (9 currently), & Processor Family Platforms (19 currently).

https://dodoid.com/dcft

One can even click on the individual models and see a full page dedicated to that model/platform.

Some relevent deep links for the ASUS KGPE-D16:

https://dodoid.com/dcft/machine/server/asus/kgped16.html
https://dodoid.com/dcft/machine/template/fam15h.html
https://dodoid.com/dcft/machine/template/fam15hcoreboot.html
https://dodoid.com/dcft/machine/template/fam15hcorebootopteron.html

Even has a source git repo for the DCFT:

https://git.15h.org/Dodoid/dcft

Excellent work, Dodoid.

Interesting article about the KGPE-D16 from 3MDEB’s @miczyg on 2022-02-03…

KGPE-D16 open-source firmware status

https://blog.3mdeb.com/2022/2022-02-03-kgpe_d16_status

Introduction

Today’s computing systems and processors are becoming more and more efficient but closed as well. Closed in terms of documentation, closed in terms of free and open-source software and firmware. The x86 silicon vendors are striving for security by obscurity, falling deeper into the pit they created themselves, bound by laws that were supposed to protect them. As a result open-source firmware community has to struggle and push vendors into openness or to provide means to run open firmware on their products. The openness and possibilities to run open firmware is gradually decreasing over time as vendors create more and more binary blobs, offload various operation to another entities (e.g. AMD PSP or Intel ME). These entities are often fed with more firmware and blobs, often closed and proprietary with source code being the vendor’s restricted secret. In the light of this threat we turn our eyes to older platforms that were free from firmware blobs, embedded secondary microcontrollers in chipsets with ring -3 capabilities and were truly user-controllable, respecting the freedom and privacy. We just hope the days of open specifications and trustworthy computing on x86 architecture (which were present not so long ago - just over 10 years ago) will be back once. One of the most performant and still blobfree platforms you will read in this post is ASUS KGPE-D16, dual socket AMD Opteron server/workstation board released in 2009, FSF RYF certified.

To the rescue of KGPE-D16

It has been a huge blow for the community believing in privacy and liberty of the hardware. Thus 3mdeb tried to answer on the community requests and needs to bring back the platform. To prevent the board from dropping (half a year before the 4.12 release at the end of 2019, where the deprecation has been announced) 3mdeb has applied for funding to NLnet Foundation, unfortunately the project to improve the quality of board support has been rejected. The application can be found on 3mdeb’s GitHub

The hope was almost lost. In the meantime 3mdeb propagated the need to protect the libre hardware like KGPE-D16 on various events like, e.g. FOSDEM:

FOSDEM'20
FOSDEM'21

Agreed with 3MDEB on the enduring value of the KGPE-D16.