I’m on a modern platform (Intel B760), and am looking to set up some kind of trusted boot so that I can multiboot somewhat more safely. However, Windows 11 requires TPM 2.0 and Anti Evil Maid requires TPM 1.2.
I don’t think that’s what I’m looking for, since Heads is a firmware replacement IIRC? Also I doubt it supports modern desktops, I only see laptops on the flashing guides.
Its a coreboot payload, so it definitely supports modern systems, but yes, it’s primarily geared toward laptops. It’s also questionable how well it would work with Windows, but then again, you’re not supposed to be using multi-boot with QubesOS anyway.
Unfortunately, until gaming becomes possible on Qubes, I can’t really do a non-multiboot setup. Also, I doubt coreboot is compatible with modern (12th gen Intel CPU-supporting) chipsets/motherboards, because I only see pretty old (7th gen) motherboards on their compatibility list: Mainboard-specific documentation — coreboot 24.02-112-gec7b480760 documentation
I also heard that coreboot’s performance isn’t as good as stock BIOS because it isn’t as aggressive as stock BIOS, and performance is important to me.
Okay so my last post got spamfiltered but do you think there’s a way to move my /boot onto a USB drive so I can just plug that in when I want to use Qubes? Although that might be compromiseable by some BIOS implant or a malicious VBIOS flash, but that’s really outside of my threat model (and malicious VBIOS would affect Qubes anyway, even with AEM right?).
If this is possible, are there other security impacts?
I’m pretty sure that’s possible, yes, though it’s not really measured or verified boot, obviously…if an attacker were to have physical access to your system (or remote access, especially when you’re using Windows) and compromise your BIOS then you won’t detect that if it’s well done.
Have you tried using Windows VMs inside QubesOS? I’ve found that I don’t need Windows at all anymore…I just do most things in Linux (inside QubesOS) and the occasional Win-only app I run in a WinVM. But then I’m not really a gamer.
If you have only one system (QubesOS) then things get much easier, e.g. even if you don’t want to use Heads you could still use the open-source coreboot, which offers some kind of verified and / or measured boot as well, even without Heads IIRC.
True. I guess I should tie the BIOS write protect pin to ground then, if I go that route. There is still the issue of the VBIOS theoretically being flashable (not going to take apart my GPU to tie the VBIOS write protect to GND lol), as well as state being stored in a large quantity of other random controllers which I have no idea how to protect.
The games I play have anti-VM protection, because apparently people use VMs to cheat in games. Therefore, Windows qubes are not likely to be suitable for my usecase.
Actually, how likely are BIOS/VBIOS/whatever-firmware-based persistence tactics for normal people? I’m not NSA or anything so my threat model absolutely does not include state-level actors burning a chain of 0days to hack me LOL. I’m just looking for a little bit more security than using any Linux distro.
Well there’s a difference between getting rootkitted from Windows vs. from QubesOS (the latter making it much harder for a remote compromise attack to succeed).
Also you don’t have to be “NSA” to be a juicy target…maybe the attacker wants your money or crypto or other valuable stuff you have or there are political / social etc. factors involved.
But yeah, I’d say if this is what’s keeping you from using QubesOS for most things (e.g. aside from gaming) then you’re probably better off just going with a dual boot system without verified / measured boot and accepting that the setup is not optimal.
You’ll also have to assess the factor of physical security, as verified / measured boot play a big role here. If you live in a secure neighborhood without anyone being able to easily access your computer then probably that part of your thread model can be deprioritized, generally speaking.
Also true but it’s def not worth burning a 0day on me LOL.
I mean there’s also the lack of GPU acceleration, wonky vimeo playback, general sluggishness, and such. I like having a secure workstation but sometimes it’s just unusable.
I think I should be fine on physical security (LUKS will protect the data if my computer gets stolen and I don’t expect to get hacked via physical means, let alone getting 0dayed by BIOS implant), but yes verified boot would be nice for some additional peace of mind.
BTW, does AEM protect against VBIOS/other DMA attacks/generally attacks by peripherals who “turned to the dark side of the force”? If not, then I might just tie the write protect pin of my BIOS chip to ground, move my /boot to a USB, and call it a day.
Might not have to be a 0day, depending on your setup, but I get what you mean.
Qubes4.3 should get you excited, then, as the aim is to allow for iGPU acceleration to be enabled in domUs in a relatively secure way (hopefully). Release date TBA…not soon.
Not if the attacker is more sophisticated: e.g. he breaks in, images your LUKS container, plants a “bug” (compromised BIOS, keylogger, a hidden camera to shouldersurf, whatever else) and gets your password that way; then the attacker can decrypt his copy of your container.
Don’t know for sure but I doubt that AEM scans the entire system for malicious devices, e.g. some device plugged into a port of your mainboard.
The reason I wanted to use AEM was so that hypothetical attacker needs a 0day and 0days are outside of my threat model because nobody burns them on internet randoms LOL.
Wasn’t virtio-gpu and similar like 30% of QEMU’s CVEs at some point? (I understand that software rendering is to reduce dom0 attack surface)
Oh. I guess that is something new I should worry about.
Somehow implementing TOTP in TPM should mitigate sufficiently but I have absolutely no idea how to do that.
I’ll check what it scans, because if it only scans BIOS then I know I can probably do my plan to set write protect for equivalent security. BTW, do you have any tutorials for this kind of hardware modding? I’ll check them out when I unbreak my sys-net (#8991)
Otherwise is there any security issue with trenchboot even in its currently unfinished state? If there shouldn’t be any (“no” is never real, if you see what i mean ) can I just use that?
Also sorry for late response, I wanted to reply quickly but forum ratelimited me LOL
BTW my last post got unhidden "Official" AEM-like functionality with TPM 2.0? - #7 by foxyportal
I’m running coreboot with Heads payload on a 12th gen Intel CPU right now, so it can definitely work, but of course hardware compatibility issues are a thing with Heads and you can brick your machine in the worst case if it’s not compatible (though usually it can be unbricked by manually flashing the prior BIOS again).
The exact implementation is being worked out right now and it will somewhat increase attack surface for those qubes where the user enables it, but the goal is for it to add very little risk. You can check out the progress here (early days).
That only mitigates some of the attacks I talked about, but it would be a good start…have you tried getting PCI passthrough to work with an external GPU on your Qubes machine? That may deliver sufficient performance and allow you to use only QubesOS. Then you could try to install e.g. Heads and cover a lot of bases that way. You can search for “GPU passthrough” on this forum; there are guides etc.
No, but there should be plenty online.
No idea, to be honest; I haven’t looked that much into Trenchboot to be familiar with its current state.
Holy shit, I’m going to go rig up my ESP8266 right now! (only half joking, but I’m tempted)
BTW Heads verifies itself to you via TOTP/HOTP then verifies kernel, commandline, and initrd right?
Also does your threat model permit you to disclose your motherboard? If so, could you tell me its model and chipset so I can see if it’s similar enough to mine?
Very cool!
Again, the games I play have anti-VM anticheats and bypassing is a PITA. I tried passthrough on libvirt and performance was good enough, but wasn’t anywhere near native, probably due to misconfiguration. I don’t want to deal with passthrough though, if I’m going to game I don’t want to be resolving random issues at the same time.
) can I just use that?