I bought a NovaCustom 560TU with Heads firmware because it was certified.
But it has critical obstacles to a reasonable Qubes usage.
No splittable USB-Controller.
Without that every device is on the same controller and can’t be separated by USB-VMs, even internal devices. That means a Yubikey and the Camera is in the same trust domain as the bluetooth module. That is inacceptable.
There are 3 USB Controllers in lspci:
0d.0 Meteor Lake-P Thunderbolt 4 USB Controller 8086:7ec0
0d.2 Meteor Lake-P Thunderbolt 4 NHI #0 8086:7ec2
14.0 Meteor Lake-P USB 3.2 Gen 2x1 xHCI Host Controller 8086:7e7d
I put each of them into a separate VM.
Started them. And tested all kinds of devices on every single port.
Every single device showed up in the VM with 14.0 8086:7e7d
I tried,
USB2 Combo things like Yubikey
USB3+ Harddrives
USB4 Harddrives
Thunderbolt Hub
None of them was separate. All were in the same controller as the Bluetooth part of the Intel WiFi and the camera. Regardless of which port in which mode.
The machine has shitty fan curves.
That don’t even increase when it gets over 68°C. I have to manually use the full fan button when it gets hot.
Can anyone help me solve these?
I suggest amending Qubes certification to cover actual normal Qubes usecases.
Even the old x230 had its internal devices on a separate controller.
Also I just blew 4k€ on a maxed out Qubes laptop that I can’t return because verifying all kinds of things took forever on a busy schedule.
What do I do with an expensive Laptoo that I can’t use for it’s intended purpose?
That other post is about the same topic on another device model. And no problem was solved in that thread.
And for me ALL things go into the same VM regardless of what I connect.
Overall this is a pretty good level of isolation and is similar to that of the X230 or possibly better if the displayport issue gets fixed. It may be worth disabling the camera/bluetooth in the Dasharo UEFI settings when not needed.
This is a ridiculous claim.
I don’t use Dasharo UEFI Firmware but Dasharo Heads. Tho even the other firmware has no feature for separating.
Sorry I can’t help you but I just wanted to say feel really bad for you and I know the feeling.
I had also had an issue with a Qubes verified machine that has a microphone glued
in the screen which is non-removable
Why are all these linux laptop vendors such a scam. Like they cost more than other OEMs, they don’t keep their promises, promise way too much but don’t really give a shit.
Tuxedo as well. They just don’t do firmware updates.
System76 was slightly better with Updates but still not having good quality control before release.
Purism went all in on the stupid FSF firmware stance and lied about being blob free. And they didn’t stand up to Intel either with their ME reversing.
All of them promise tooling for own Bootguard keys. None afaik ever shipped it.
Dasharo coreboot seems to have code for it but you can only use it with their bespoke efi app, else its entirely undocumented. And it seems there is no support at all for using own keys, just fusing their keys.
To be fair do the hardware vendors and the Qubes team, the certification requirements are disclosed and the bar is already pretty high.
Regarding USB controllers, the only requirement is that there is a way to have mouse /keyboard in a dedicated controller or PS/2 directly. Quoting from the certification requirements:
Most laptops use PS/2 connections internally for their input devices (i.e., keyboard and touchpad). On most desktops, however, USB-connected keyboards and mice have become standard. This presents a dilemma when the computer has only one USB controller. If that single USB controller is dedicated solely to the input devices, then no untrusted USB devices can be used. Conversely, if the sole USB controller is completely untrusted, then there is no way for the user to physically control the system in a secure way. In practice, Qubes users on such hardware systems are generally forced to use a single USB controller for both trusted and untrusted purposes — an unfortunate security trade-off. For this reason, we require that every Qubes-certified non-laptop device either (1) supports non-USB input devices (e.g., via PS/2) or (2) has a separate USB controller that is only for input devices.
Even though in an ideal world we have separate controllers for every USB port, this is hard to achieve. If you look under the hood, almost no small/mid laptop vendor has full control over the motherboard design. It’s a complex system and I do truly believe that if if vendors could get these devices with individual controllers at a competitive price, they would. You can see example of some of the attempts and failures of getting even an more frequently requested feature: hardware killswitches.
With that said, I don’t think it’s fair to approach the topic as you did here. It’s understandable that you are unhappy with the device, but (a) the requirements are clear regarding the possibility of one controller and (b) this is an advanced feature that is not critical for running Qubes – in fact, Qubes tries to mitigate USB threats with the USB proxy which in 4.3 will be even more convenient to use. But there is only so much one can do in software.
Perhaps a way to phrase your complaint is to suggest that hardware vendors disclose how many USB controllers exist in practice. That I would consider fair (and it may even be done somewhere already).
Yes I already stated, they fulfill the requirements and only the requirements.
But they have not gone the way of actually trying to use-test if it is actually good to use Qubes with it.
Yet another detail. The USB Controllers also don’t always reset properly. Which is also not explicitly stated in the requirements but it is necessary for secure operation to be able to reset the controllers properly.
Hardware vendors that manage to do that, will certainly have a superior offering in that regard.
I think you are hinting at something useful: there should hardware requirements and then Qubes-relevant hardware features,that go beyond the certification.
Examples of these (some as you point out) could be:
webcam/mic killswitch
upgradable RAM
allow for multiple sys-usb (2+ usb controlers)
A feature breakdown like this would enable a more robust product comparison. And this is something that we can already get started here on the forum. All one needs is the initiative.
My suggestion would be to add to the community-recommended computers a table with these “beyond-requirements” features. That is a wiki post, which means anyone can and is welcome to edit. All certified hardware should already be there, so I think it would alleviate your concern. Would you be interested in shepherding this?
It nice to have list of recommended hardware. But in my eyes, at the moment question is about why existing hardware in certificated device function in abnormal way.
Maybe project need a “Gold certification” with extra requirements of deep support.
Build-in camera, microphone, fingerprint reader and another sensors should have saparated controller.
Each physical side of device should have his own USB/Thunderbolt controller
On Proxmox (KVM) you can passthrough Controller, Port or even a Single USB Device (via Dev ID) to a VM… Still the devices may share a controller, but they won’t be in the same VM if only Ports or Devices are passed… But I don’t know if something like this is possible with Xen Hypervisor…
Yes in Qubes I can “passthrough” usb devices similar to proxmox. But it does not solve the problem of network devices and secret handler devices like yubikeys being on the same bus. Therefore no isolation.
Another problem is, that even with everything in one USB VM I still have to enable nostrictreset or else the usb-vm does not come up 8/10 times because it can’t be reset.
So it is not even safely usable without reboot when ignoring that:
the bus contains a network device (bluetooth)
everything shares a bus.
Because when restarting the vm, the controller can only be reset some of the time.
What does the Qubes certification say about strict reset?
and I know the feeling.