[upboundspiral]

The problem with laptops is that UEFI is a shadow operating system that keeps running after boot, with a bunch of security vulnerabilities. Furthermore all Intel / AMD chips have a microprocessor state called SMF which if you trigger it basically gives you carte blanche to do whatever you want.

"Trusted Boot" is a meme on x86. If you really want something like that you need to do what Oxide Computer is doing and rip out UEFI for good and implement your own secure boot chain.

Qubes is great but at the end of the day cannot protect against evil maid attacks to the level that pixel or apple phones can. Its great at making sure a browser exploit cannot steal your banking credentials you have open in a different virtual machine but cannot overcome the limitations of the platforms it builds off of.

So I understand why the GrapheneOS folks do what they do.

See also: "X86 considered harmful" by the founder of Qubes OS (posted in 2015!)

https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf

[fsflover]

I use Qubes with TPM and Heads and with a hardware key. All based on FLOSS, so its possible.

[handedness]

You still need to address this part: "Qubes is great but at the end of the day cannot protect against evil maid attacks to the level that pixel or apple phones can. Its great at making sure a browser exploit cannot steal your banking credentials you have open in a different virtual machine but cannot overcome the limitations of the platforms it builds off of."

That's the crux of it you blow past every single time it comes up, and then disparage others as having not stuck around long enough to educate you (as if that's their responsibility).

[fsflover]

> "Qubes is great but at the end of the day cannot protect against evil maid attacks to the level that pixel or apple phones can"

Yes, it can. Heads, TPM with a hardware key do exactly that, don't they? I'm not sure what you mean by "level". You would need to use a nail polish, too, to be sure your laptop wasn't tampered with.

> but cannot overcome the limitations of the platforms it builds off of

Yes, it can, if you use it correctly. Tell me your threat model, and I will explain how Qubes can protect you.

[handedness]

Comprehensive verified boot with hardware attestation, a secure element, no dependency on USB for AEM. It's an entirely different ballgame.

Qubes AEM hasn't had an update in years, either.

[fsflover]

Perhaps you are right, and the hardware attestation is more reliable on a Pixel. However, doesn't it rely on proprietary hardware, unlike Heads? coreboot with Heads is not the same as Qubes AEM. Heads is updated regularly: https://github.com/linuxboot/heads/

[upboundspiral]

Heads + TPM is solid but I suspect it is not at the level of Google/Apple secure enclave. And a strong secure enclave provides benefits outside of first boot to secure certain processor state and continuosly ensure integrity.

For desktop TPM at least to me they seem a bit of a black box with many past vulnerabilities https://en.wikipedia.org/w/index.php?title=Trusted_Platform_....

I think at cold boot as long as one doesn't store the encryption key in the TPM (external hardware key?) then one should be secure. I am not so sure about post boot however, once the system is already running.

This actually prompted me to research a bit on the scale of the security impact of SMM

https://en.wikipedia.org/wiki/System_Management_Mode

https://doc.coreboot.org/security/smm.html

It seems that coreboot is aware and supposedly for some computers can be implemented to catch calls to SMM (ideally this would prevent the attacker from triggering SMM - if they do it's game over).

I do suspect though that if the system bus is not protected from malicious calls then someone can trigger SMM and have carte blanche to one's computer.

https://www.infoworld.com/article/2167684/hackers-find-a-new...

https://hothardware.com/news/researchers-discover-rootkit-ex...

I don't know what processes Apple / Android use but I suspect ARM chips don't have SMM and that they tie certain functions to their secure enclave. In X86 its backwards, with SMM having control over the TPM (at least in some implementations).

Though some SMM vulnerabilities are patched by now given its history I take X86 security with a grain of salt. I think the potential for a secure platform is there, but I suspect one would want to make their own boards engineered with security in mind to be certain (I hope this happens in the future - it seems to be happening in the server space already).

[fsflover]

> external hardware key?

Yes: https://en.wikipedia.org/wiki/Librem#Librem_Key

[handedness]

Versus storing the encryption key on a device requiring USB with its many vulnerabilities (even on Qubes OS), storing the key in a dedicated eSE is beneficial.

Beyond that, there have been known vulnerabilities of NitroKey's Librem Key, to say nothing of the Nitro Key App.

Nothing's perfect but I would vastly prefer something like the Titan M2's implementation over a USB key with all of the complexity and attack surface that introduces.

[handedness]

Adding: Qubes is really no better, and maybe worse in some ways, than having a discrete banking VM in your bare metal Xen hypervisor. Sure, there are some improvements such as handing input devices over to an appVM, those sorts of things one could do in Xen manually, but broadly speaking the value Qubes bring is it does an amazing job of making living out of a Type-1 hypervisor barely doable for some small subset of people. And the "barely" and "small" is increasingly shrinking with each major release.

The magic of Qubes isn't its isolation, it doesn't even provide its own isolation. Qubes is an integration layer added on top of an isolation foundation. So you have a clipboard, file transfers, window dressing, easy configuration of device pass-through rules, all that. It's great.

It's phenomenal at that. But you have to understand what it is. You have to layer on a whole bunch of additional cruft to the Type-1 hypervisor, potentially all of which introduces potential vulnerabilities to dom0 and/or relevant appVMs. (Fortunately the project moves very slowly even for its size, which gives me some reasonable degree of confidence in its third-party code contributions, if less than I have in GrapheneOS's team's contributions.)

GrapheneOS solves a lot of these practical issues in very real and excellent ways, and it does it in large part via its tight integration with the excellent hardware it runs on, "Google" notwithstanding. (Now, "Motorola." "Lenovo." "China." A poor architecture even when made in America is not a practical improvement.)

Qubes-by-way-of-Xen does it despite running on pretty horrendous architecture. Even with your labor-intensive and super geeky improvements you've made to your setup, an evil maid attack, a theft, coercion, legal and political forces, all of these factors hit a harder target in GrapheneOS than they do in any QubesOS configuration currently achievable. But, as stated, trying to contain the most dangerous software most people ever run, a web browser, from leaking into your password manager? It's great. If that's your primary threat model, it's difficult to beat. Profiles on GrapheneOS are also excellent for that, if less well-integrated and therefore usable as Qubes.

Qubes still wins in terms of virtualization, of course, and you're comparing the benefits of virtualization to all of the many other benefits GrapheneOS brings (and in many instances iOS too), but you're not comparing them meaningfully.

Type-1 style virtualization is on the GrapheneOS roadmap, and once they achieve that it will be vastly more secure than QubesOS running on any x86 concoction you can devise. Give me a ThinkPad that meets GrapheneOS's hardware requirements running a virtualization-based GrapheneOS implementation and I would have little reason to ever run Qubes OS again. That would be some kind of peak practical end-user security solution, and I'd imagine enterprise and state customers would flock to that, if the broader enterprise requirements of it all were met, too.