This is C/C++ flashed to the SPI? Or it is on die as a binary blob?
Never run anything? Thatâs not going to work for most usersâŚ
I get your point, you shouldnât use dom0 to run random applications, or things where the full functionality isnât plain to see.
Iâm talking about things specifically designed to run in dom0, that can only run in dom0 - scripts that are less than 100 lines long, often shorter, some of which are included as part of shaker or qusal, others that I wrote myself and keep in a sys-git
Running third-party ELF files in dom0, I agree that would be quite insane, if thatâs what you were thinking of
can dm-verity be run from within heads?
The microcode gets uploaded to the CPU during boot.
Once QubesOS developers have switched dom0 to be immutable, which might be a few years away from now, they can generate the signed dm-verity data for the dom0 image. SecureBoot or Heads would verify the Linux kernel and Initramfs image are properly signed by QubesOS, and of the expected version, and the Initramfs image will then contain the verification key for dm-verity, and mount the dom0 image with dm-verity enabled. That is, neither SecureBoot nor Heads will do that part, they will just verify that the booted kernel is genuine, and then the kernel will take care of dm-verity.
(Actually, SecureBoot or Heads will verify the Xen installation, which would then verify the kernel booted inside the dom0 VM, to be more precise.)
You cannot set up any of this yourself, but would have to wait for QubesOS developers to implement it. The risks dom0 will be compromised are already extremely small, as long as you donât run any commands or scripts inside it.
Just curious, what is it you feel you have to do in dom0 that requires running scripts, that cannot be done in an untrusted VM?
I never run anything in dom0.
I like when you ask about my feelings, youâre a true gentleman 
Iâm a little surprised that you canât imagine any task needing to be performed in dom0, but happy to share some of the things.
- Scripts to monitor hardware, dom0 resources and VM resources is one of those things
- Simple btrfs filesystem maintenance (e.g. defragmentation)
- libvirt hooks for dynamically configuring cpu affinity/pinning, eventually to be replaced with extensions to the domain xml files when I work that out
- Some simple performance testing scripts, to identify regressions, mainly performance of the storage pools
- Miscellaneous diagnostic scripts, some to automate identifying âissuesâ proactively, by looking at VM/DM logs, others invoked manually as needed
- Small wrappers around editing of certain files (like /etc/default/grub) to keep a nice stack of backups with timestamps around in case I need to roll back xen or linux command-line changes
Yes, some of these tasks could technically be run from an air-gapped vm, by poking qubes rpc policy holes to dom0 and/or developing custom qubes rpc services in dom0, but I have enough professional experience to determine when that effort is worthwhile and not counterproductive. And, once again, auditing a shell script that is less than 100 lined is not difficult or error-prone
After those âsystemâ type things, which I donât use that often, the other category is usability/convenience/productivity, for interacting with qubes efficiently without any distraction. The three I use most commonly:
- run new terminal in the VM that currently holds focus, < 10 lines of bash
- run a terminal in the VM that was most recently created, < 10 lines in bash
- pop a primitive dialog to lock screen, with a few choices for locked power management profile / restore profile after unlock. 20 lines in bash
I also have a custom qubes rpc service (20 lines script) in place to provide actual persistent attach of USB devices that doesnât depend on the device being plugged into a specific port. This will go away soon as qubes devs complete the native solution, itâs currently in progress in qubes-issues.
I donât recommend anyone do this unless they have relevant experience to implement correctly, audit and test.
2 Likes
Oh, okay. I think literally all of those examples are way way beyond what most people using QubesOS would ever think of doing. The qube manager and applet already have all resource usage information I would need, and I use a default configuration for qube storage, so LVM, not btrfs, and LVM doesnât have anywhere near the same performance issues like btrfs have when images gets fragmented, and the rest seem to be very technological testing and diagnostic use cases only developers would need to bother about.
I was mostly asking trying to understand if there is some functionality that is missing in the user interface for QubesOS. Persistent attaching of USB devices, but that is already planned as you say.
Guess again⌠
You may say that now⌠
Quite a lot of terminal commands offer much more flexibility than the provided GUI interfaces, and many people (myself included) can make them do what they want them to do much easier and faster using scripts. Some commands even offer extra options currently not provided by any GUI interface.
1 Like
What is an airgapped VM?
Can the gui-VM perform these system administration tasks?
Very possibly, though not sure, as I donât use sys-gui
microcode is loaded into the CPU from the SPI chip.
1 Like
I donât know either, but it depends on how QubesOS have implemented that. If it is displaying graphics only, it cannot send input to any qube, but in the case where sys-gui deals with input too, it can likely do anything. But in that latter case, the benefits of running a sys-gui qube seems more questionable to me.
No? What is an SPI chip?
The UEFI firmware will load CPU microcode during early boot, before booting any OS. The OS might have a newer version of the CPU microcode, and might thus decide to load it themselves too. This is what QubesOS do during bootup.
The end user. 100%.
Hashing up to 20GB (dom0 logical volume size) before every boot would take a very long time on most hardware, unless you had access to a mining ASICâŚ
There are things you can do, like watching for execution of any qvm- commands or other processes being spawned.
Oh how I wish IntelME was actually on an SPI flash chip that was external to the CPU. Then it would be so much easier to get rid ofâŚ
Sadly, itâs inside the CPU itselfâŚ
These were essentially some developers at Intel/AMD who were trying to do something smart, so the CPUs didnât work as hard, and could be pushed harder, by keeping track of all the instructions issued so far, then âguessingâ what the next one would be, and actually doing it before the program even asked for it. It was called âSpeculative executionâ, and was supposed to increase efficiency and throughput, and reduce power consumption on CPUs.
The problem was, if you gave it the right instructions, you could trick it into thinking that you wanted to read some RAM that your program wasnât supposed to have access to (âout-of-bounds memory registersâ), and it would just do it without a second thoughtâŚ
It was a very nice idea with excellent intentions that went horribly wrongâŚ
Intel & AMD have released patches for some of their CPUs, but not all of them. If Linux detects that your CPU is vulnerable to exploitation, its response is now to disable that feature entirely.
If youâre curious, the bottom of the output of lscpu will show you what your CPU is vulnerable to.
So if your CPU didnât get a microcode update (like a few of mine), donât panic. You just have to be careful what you run on it, and factor it into your threat model, knowing that anything you load in it, even unintentionally, could exploit it.
You either have to accept that, or cough up the cash and get a new CPU/machine.
Like, I wouldnât be running a Tor node or anything like that on one of those CPUs, unless I made sure that the memory registers didnât have anything of any value in them, and I had strong secondary network devices guarding and containing it.
But those CPUs make for great offline devices, media players, emulation devices, or anything on trusted contained networks.
And yet, @Churros, this is genuinely what âSecurity Professionals in the corporate worldâ believe is âthe only way to secure a machineâ. They have extreme difficulty comprehending the Qubes OS security modelâŚ
âŚall of which could be easily circumvented with a simple reflash of your BIOS chip using a factory binary,
UmâŚyes you can. You just have to know what you are doing.
The reason none of that has gone anywhere is because they havenât found an approach that isnât fundamentally flawed, making it a waste of energy to produce.
Once this is solved, then of course it would be a no-brainer.
At the moment, the best solution so far is a way to keep track of, in as much detail as possible, the state of your machine from when you last shut it down, to the state it is now that youâve turned it back on; and then giving the user the choice of what to do next.
A qube without any network access. In the standard vanilla Qubes OS install, the vault qube would be a good example.
If you create a policy in dom0 that allows it to, then yes. Basically, any qube can do anything to any other part of the machine, as long as dom0 says itâs ok.
Naturally, almost everything is set to deny, thoughâŚ
On some machines, particularly older ones, this was the case. Some older CPUs actually had flashable onboard memory.
Intel/AMD then started moving to a model where they would have a base ROM running inside the CPU that would contain instructions like âcheck for microcode and execute if presentâ at regular intervals in their program.
This is why on Linux nowadays, itâs either in the initramfs or in its own separate image file on the boot partition. Makes it more modular, flexible, and it means that if releases an update, you donât necessarily have to recompile the other.
X11 can most certainly inject input into a program. Thatâs what it does every time you click the mouse. If youâve ever done X11 forwarding over SSH, X11 is injecting that input from the remote machine to your daemon. Itâs what it was designed to do.
The benefits of a sys-gui qube are more apparent when you might want to âloan outâ a Qubes OS machine, but you want to be able to retain control of certain parts of it.
For example, kiosk machines, communal Qubes OS computers in a public library, or giving a restricted/monitored Qubes OS machine to your children.
Work machines are another good example of this. You wouldnât want employees to be able to change dom0 policies, so youâd either add a root password, or youâd create sys-gui for them to interact with.
Of course, this is fundamentally flawed if they just remove the drive and unlock the LUKS partition on another system, but the use case remains valid⌠
Itâs a tiny flash chip (itâs about 7mm x 7mm, usually had 8 legs, and can store 8192Kib on it, although some on newer machines can store upwards of 64MiB) that is on the motherboard of most PCs that contains the BIOS/bootloader/u-boot/UEFI.
When you first put electrictiy through the motherboard, it is one of the first components to be powered.
Sort ofâŚ
https://wiki.gentoo.org/wiki/AMD_microcode
The microcode updates on Linux used to be taken from /lib/firmware once the kernel had fully loaded.
Now, and on any kernel after 6,6, because people found out ways to hijack that process (according to Intel/AMD), microcode is now loaded by GRUB at the same time as the kernel, and placed within the initial ramdisk, or as a its own separate ramdisk.
1 Like
Why are they moving the CPU microcode from the CPU die, to the SPI, and then into the kernel?
What is the reason for this and why move it away from the hardware? To make more transparent?
Which generation of Intel CPUs does IntelME apply to?
Which generation of Intel CPUs can switch off IntelME using the HAP bit switch in UEFI/BIOS?
Some methods allow for the removal of microcode firmware modules associated with IntelME
but are not strictly necessary to boot and run the CPU. This is disable+neuter method.
In my research, 2008 appears to be the year ME became mandatory to initialize the CPU.
HAPbit ME < 11 and AltMeDisable bit > 11
There is no clear argument if using these software switches is sufficient to fully neutralize
IntelME.
Theyâre not moving anything.
- The CPU has onboard firmware
- This onboard firmware can run by itself just fine
- The firmware has been written with breaks in the code to check whether âmicrocode updatesâ are present
- If microcode updates are not present, the CPU will continue execution of its onboard firmware
Well, if they only want to change one little portion of the firmware, they donât have to reflash the entire chip.
They also have designed the CPUs in a way that the chip shouldnât respond to anything trying to do a ROM dump.
Iâd be surprised if anyone knew that off the top of their head. Check the Intel Ark.
What is the location on the CPU die with the firmware flashed called?
Is this C/C++?
Anyone who does know this has probably signed a non-disclosure agreement.
No, THIS is C:
#include<stdio.h>
int main(void)
{
printf("This is NOT what is inside a CPU.\n");
printf("A chip cannot understand programming languages.\n");
printf("Only binaries\n");
return 1;
}
âŚand THIS is C++:
#include <iostream>
using namespace std;
int main() {
cout << "This wouldn't be on a CPU die, either" << "\n";
cout << "But it would be a cool way to hide information" << "\n";
cout << "Anyway, point proven." << " I crash now.\n";
return 2;
}
This is NOT what is on a chip.
The human who wrote the source code of whatever is running on the CPU die could have written in literally any language they wanted, as long as it successfully compiled into a binary that the chip could understandâŚ
I realize it is ultimately compiled into binary, but the original programming language was not stated
C/C++ are not considered to be inherently memory safe programming languages.
A cpu interprets opcodes.
They are as safe as the thoroughness of the human programmer.