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-Desabled 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 sayin 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/