I have various devices that require me to install Windows-only software to update the firmware. Has anyone had luck doing that on Qubes with an emulator?
By design the Qubes don’t touch bare-metal. Getting one to update the firmware would be a “bug”.
Personally, I ignore it given how I manage my system. If I really needed too I’d take out my Qubes system disk, load Windows on another disk, update the firmware via Windows, then replace the Windows system disc with Qubes. I always try to keep my Qubes-only system isolated and stock.
Wow I had no idea I could install Windows in a qube. I did that and attached a USB device needing a firmware update and was able to update it no problem.
Interesting. If you check the BIOS when booting is Intel ME at the expected version?
The updated device isn’t a computer, it’s an external USB device. I should have made that more clear.
Also to get USB working in the Windows qube I had to issue this command and then restart the qube:
qvm-features name_of_Windows_qube stubdom-qrexec 1
Well, if you trust Windows won’t mess with your hardware and it’s firmware, then you don’t need Qubes actually.
You’re suggesting I install Windows on the hardware?
No. I’m suggesting that the hardware that was exposed to Windows isn’t considered safe anymore for Qubes. At least not for me.
In what ways does installing Windows into a qube expose the hardware and firmware to being compromised?
The computer is probably fine, as long as you’ve got sys-usb and are using Qubes the recommended way.
The USB device you just updated, however, was in direct contact with Windows and was altered by that operating system when you did the update.
I believe what tempmail is saying is that they would no-longer trust that USB device because Windows is inherently not trustworthy.
1 Like
What you do with that information is up to you. It’s not irrational to quarantine that device.
I personally don’t trust devices that have touched windows machines, or any other OS, really.
On the other-hand, depending on who made the USB device and how they manufactured it, it very well might have already come in contact with Windows before it was even made available for you to buy.
1 Like
I agree that the USB device deserves quarantine. After re-reading tempmail’s message I see that must be what he meant.
Unfortunately not only that… beside device, whole USB controller is exposed as well, so no trust to that controller('s firmware arguably gets poisoned) too. And many of today’s laptops have only one USB controller…
1 Like
@tempmail does have a point. Since you cannot be 100% sure what Windows is actually doing (unless you were involved in writing the code and your test binaries match the production binary…), there is a chance that Windows might have done extra things while it was updating the device firmware. And those extra things could be literally anything (it’s what is known as “arbitrary code execution”).
That’s one of the reasons why we keep it inside an environment that we can control (as much as possible), so that when the software asks us for access to things, we can pick and choose what it gets to touch 
@Fan is also right, in that it is highly unlikely that anything had happened to your USB controller in the process of passing it through to your Windows Qube.
But, as has been said millions of times before in this forum, it all depends on your own threat model
I would sincerely hope not. If it did work, that would basically show that all the compartmentalization in Qubes OS wasn’t working properly…
At least, with anything internal on the machine. USB devices, maybe…
If I may, I would like to elaborate on what you said, and bring up a few important clarifications (respectfully, of course).
Don’t we all? 
Just about every serious Linux user has peripherals that say “Requires Windows, MacOS, iOS, or Android”. But we still make them work 
The best one that I got was an IT professional telling me that my SeaGate hard drive was “not compatible with Linux”. I was also shocked at how proudly and matter-of-fact he said it. Gaslighting at its best, ladies and gentlemen… 
I’m assuming you mean that all the manufacturer gives you is a Windows EXE file.
Sadly, most do, unless you pay them big money (like if you’re running a server farm). Then, they might even be nice enough to give you the source code 
Thankfully, there might be a silver lining. Often, manufacturers will simply just sandwich the firmware into the EXE file, allowing you to unpack it (if you know what you’re doing).
My second point. You have to ask yourself the following:
- What does my device actually do?
- Is the current firmware/driver sufficient for my needs?
- Is the firmware/driver actually flashed to the device?
- Or is it simply installed on the computer it’s connected to, and then loaded into the RAM (most firmware/drivers are like this, because it’s cheaper for the manufacturer)?
- Does this firmware update:
- Add functionality?
- Fix bugs?
- Patch vulnerabilities? - If it doesn’t do any of that, then do I still need it?
- If the answer is yes, is there any other way I can achieve the same result without running what is essentially a black box on my computer?
- If the answer is no, then is there a way I can get the firmware update without compromising any other part of my system?
- If the answer is yes, is there any other way I can achieve the same result without running what is essentially a black box on my computer?
A good example of this is motor vehicles suddenly needing “software updates” every time you service them. It took me a good several months to explain to my family that they essentially bought an internet-connected always-on “diesel-powered computer on wheels” that they cannot control in any way.
Spoiler - It’s not because they figured out a better way to make the doors lock, windows wind down, or ignite the diesel and make the wheels turn…
If you still want to use these devices with your machine (which is entirely your choice), it will likely be possible to pass them through to a Windows HVM and execute the manufacturer’s binaries there.
That should be sufficient for most USB devices that have on-board firmware.
All of this comes down to the choices you make in your computing, and this also includes your choice of hardware (both present and future).
Again, all of these choices are entirely yours and nobody else’s. Our job is to make sure you make the most informed decision you can
HARDWARE MANUFACTURERS’ DICTIONARY:
In general, with exceptions, of course…
| What they say | What they usually mean | How Linux users respond |
|---|---|---|
| “The device will only work with Windows or macOS” | “We wrote drivers for Windows and macOS, and no, we are not going to give you the source code” | “A USB hard disk will only work with Windows or macOS? You’re kidding, right…?” |
| The device driver is our own unique implementation | “The driver is either absolute garbage and full of security vulnerabilities, or we are artificially restricting the capabilities of your device, and you have to give us money if you want us to remove those restrictions, or it does something that we don’t want you to know that it’s doing.” | “Why is your driver 800MB…? Also, check it out, I got your USB printer to mine Monero” |
| “We only release tools for Windows and iOS” | “Our main market comprises of mainly Windows and iOS users, and we need to take care of our main market.” | “I will gladly write a Linux driver for you. I’ll even do it for free. Please, will you let me?” |
| “This is a required update” | “We either made a massive blunder initially, and our lawyers need us to say this so we don’t get sued; or we’ve added something that we’d rather not talk about…” | “What you think you’re some kind of a Jedi waving your hand around like that? I’m a Toydarian! Mind tricks don’t work on me…” |
| “Various other security fixes” | “If we admitted on record that we sold devices that allowed arbitrary code execution, we’d be liable for millions in compensation” | “Whoever wrote that update description must be really proud of themselves right now…” |
| “We have pushed our firmware upstream” | “We don’t have the resources to maintain our drivers, so we’ll let you guys do it for us for free” | while simultaneously  |
3 Likes
I didn’t realize that a USB controller can be compromised even if it is the only thing that’s exposed. Connecting a USB controller to a qube gives that qube permission to rewrite its firmware?
interesting…
so if i installed a windows qube and passed through a usb device, theres chance for firmware rewrite, usb controller attack vectors etc?
What if my system had pre-installed windows from the manufacturer. Would it not be tampered by windows already?
In some cases, to a certain extent, yes. That’s one of the reasons why sys-usb is designed the way it is.
Under the right conditions, to a certain extent, possibly.
I should stress that firmware is simply a program that’s running on the device. Nothing more.
It’s very rare to find “dumb” peripherals (peripherals that are purely electrical circuits, and you can literally see the electricity go into one end, and predictably go out the other end) these days, because microchips are so cheap and widely available.
Dumb peripherals also don’t do much in terms of functionality 
Think of modern peripherals just like programs.
| Input Signal/Data | → | Processing | → | Output Signal/Data |
|---|---|---|---|---|
| Something goes in | → | The device does something with that input | → | Something comes out the other end |
| Ethernet Packet Comes In | → | Convert to USB Protocol | → | Send to USB controller |
| Receive PCI Signal from CPU | → | Convert PCI signal to Graphics & DisplayPort Protocol | → | Send to Display |
It’s the processing step in the middle that is essentially the firmware.
Just like ANY other computer code, the only limit on what the firmware can and can’t do is what it has access to, and if other system devices/components respond to and fulfill its requests.
This means that if a USB mouse suddenly asks your kernel for a RAM buffer, the kernel will do it if it has been programmed to do so (or in some cases, if the kernel has not been programmed to deny such a request…).
The reason Windows is often used as the quintessential example is that nobody is really told specifically what those EXE files are doing, step-by-step.
No, Windows is not the only thing that could do it. ANYTHING could do this, as long as the device has been programmed to allow it.
This is one of the reasons why Qubes OS denies hardware acceleration by default. Under the right conditions, it could be possible for a VM to overwrite a device’s firmware with something nasty, if it allowed enough access to it.
Similarly, in the right conditions, it would also be possible for a device to interact with a VM in a way that you might not want it to.
I hope this makes sense
Can you think of any other interesting ways in which the software running in a qube could tamper with software/firmware outside of that qube? I would think it always requires facilitation by the user such as it does in this case where the user attaches a USB device to a qube.
By the way, how is hardware acceleration enabled/disabled in Qubes OS?
This has the potential to get very complex very quickly. But, off the top of my head:
- Making a USB device do something nasty, depending on what qube it is passed into
- Persistent Firmware
- Taking advantage of anything that is shared amongst all qubes
- Shared Resources
…but I promise you, there are definitely more.
True, all code requires facilitation (input), but that facilitation doesn’t necessarily need to come from a person.
For example, in Windows, if a drive contains a file called autorun.inf in it, Windows will blindly do whatever is contained in that file as soon as you insert the drive.
You’ve most likely encountered this if you ever inserted a CD-ROM into a Windows machine, and a launcher for the software showed up on the screen
It was intended as a convenience feature, but it has huge potential to be abused for malicious intent.
SOURCE:
1 Like