Blast from the past for me, though primarily interacted with the complementary Whonix side of things. Not surprising to read, considering how lean Qubes was from the get-go designed to be it makes sense that most things are from resulting upstream rather than with their code.
Fully aware that it was never the goal for Qubes, but I have never been able to shake the idea that one could leverage their architecture in ways beyond security hardening, especially that screenshot with MSFT Office running in its own guest got my mind spinning back then. Might be worth revisiting some old ideas I'm just recalling, especially with there having been over a decade in development across many projects focused on hypervisors by many smart people, making a few old experiments likely less impossible.
I had the exact same thought back in the day. The security isolation is obviously the main selling point, but the way Qubes handles seamless GUI integration across completely separate domains is technically beautiful.
With modern CPUs having much better hardware virtualization support than a decade ago, building a developer-focused OS that leverages that same compartmentalization (e.g., isolating different client environments or dependency hells without dealing with Docker's quirks) feels a lot more viable now.
Ehhh, I think most engineers that actually want this are pretty accepting of their current tooling and wouldn’t want to switch to a whole new Linux distribution just for a slightly more seamless experience. Besides, the people who care are always pushing forward to make the UX better — see devcontainers, Apple Containers, WSL, etc.
While user count can affect absolute disclosure volume it does not drive the main comparison in my paper. What I do is to use Xen advisories to measure upstream dependence: how much of the Qubes public advisory record is attributable to Xen/CPU/upstream components rather than Qubes core logic? That attribution result is internal to the Qubes record, so it is much less sensitive to Xen’s much larger user base.
I would recommend having a look at advanced side-channel PCIe bus DMA taps used by game cheats. They use a second computer along with an external HDMI mask-overlay mixer, to dump the target computers internal game-engine state through unencrypted DMA access to the overlay channel. Thus, gives the cheaters x-ray vision and aim-bot features for games protected by kernel level anti-cheat software.
it would be at a low enough level to reprogram IOMMU unless a hypervisor will prevent it.
if you have a hypervisor you can prevent the other to do the dma freely in memory because u can use iommu and things like amd-vi to separate it good. but if you dont have the hv below it, any devices with dma can do the duty across entire ram.
The big labs tend to do that as part of their red-teaming efforts. If a model actually escaped Xen/KVM/ESXi, we'd know it, partly because that'd be an amazing accomplishment for the lab that managed it and partly because you'd hear me running whilst screaming, off to live in the woods.
Part of why I found it very irresponsible the way the Mythos Preview system card talked about escaping a "secure container" and "secured sandbox" [0], without ever outright saying what it was in the paper. Reading between the lines, it becomes clear that it was a docker-like container or runc or something of that sort, which is A.) not a security focused solution sufficient if one thinks these models are existentially dangerous (if someone in a virology research lab broke SOP and used unsuitable clothing for PPE, I'd view that equally critically) and B.) lead to a lot of attention and concerns as without reading between the lines it was easy to conclude that they were talking about an actual hypervisor escape, which is on a very different level and which Mythos Preview most likely would have failed at considering this line [1]. Also raises the question why their regular "secured sandbox" wasn't "properly configured with modern patches" when Mythos Preview 1 was for a while to dangerous to release...
[1] "In addition, in a more challenging sandbox evaluation, it failed to find any novel exploits in a properly configured sandbox with modern patches."
Blast from the past for me, though primarily interacted with the complementary Whonix side of things. Not surprising to read, considering how lean Qubes was from the get-go designed to be it makes sense that most things are from resulting upstream rather than with their code.
Fully aware that it was never the goal for Qubes, but I have never been able to shake the idea that one could leverage their architecture in ways beyond security hardening, especially that screenshot with MSFT Office running in its own guest got my mind spinning back then. Might be worth revisiting some old ideas I'm just recalling, especially with there having been over a decade in development across many projects focused on hypervisors by many smart people, making a few old experiments likely less impossible.
I had the exact same thought back in the day. The security isolation is obviously the main selling point, but the way Qubes handles seamless GUI integration across completely separate domains is technically beautiful.
With modern CPUs having much better hardware virtualization support than a decade ago, building a developer-focused OS that leverages that same compartmentalization (e.g., isolating different client environments or dependency hells without dealing with Docker's quirks) feels a lot more viable now.
Ehhh, I think most engineers that actually want this are pretty accepting of their current tooling and wouldn’t want to switch to a whole new Linux distribution just for a slightly more seamless experience. Besides, the people who care are always pushing forward to make the UX better — see devcontainers, Apple Containers, WSL, etc.
First I heard of Qubes was when Edward Snowden endorsed it
https://www.qubes-os.org/endorsements/
https://xcancel.com/Snowden/status/781493632293605376
Author of the paper here; AMA.
BTW, project summary is here https://www.pwnshow.com/investigations/INV-006/
In comparing xen to qubes bulletins does the vastly different user count affect the analysis?
While user count can affect absolute disclosure volume it does not drive the main comparison in my paper. What I do is to use Xen advisories to measure upstream dependence: how much of the Qubes public advisory record is attributable to Xen/CPU/upstream components rather than Qubes core logic? That attribution result is internal to the Qubes record, so it is much less sensitive to Xen’s much larger user base.
I would recommend having a look at advanced side-channel PCIe bus DMA taps used by game cheats. They use a second computer along with an external HDMI mask-overlay mixer, to dump the target computers internal game-engine state through unencrypted DMA access to the overlay channel. Thus, gives the cheaters x-ray vision and aim-bot features for games protected by kernel level anti-cheat software.
Highly entertaining nuisance users. =3
Does this work with IOMMU?
it would be at a low enough level to reprogram IOMMU unless a hypervisor will prevent it.
if you have a hypervisor you can prevent the other to do the dma freely in memory because u can use iommu and things like amd-vi to separate it good. but if you dont have the hv below it, any devices with dma can do the duty across entire ram.
Unknown, but there were a few obvious bios options I saw that are needed to make the kits performant with some systems.
I still find it absurd people would go that far to cheat at a game. =3
> I still find it absurd people would go that far to cheat at a game. =3
I guess it turns the cheating into its own meta-game!
True, but a blacklisted $5k GPU seems like a bit of a risk. =3
Security claims backed by public evidence are a lot more convincing than marketing.
QubesOS is really fantastic, I wouldn't consider using anything less today.
Would need to create a lab and throw LLMs at it to see if they can break anything. That would be an interesting paper.
The big labs tend to do that as part of their red-teaming efforts. If a model actually escaped Xen/KVM/ESXi, we'd know it, partly because that'd be an amazing accomplishment for the lab that managed it and partly because you'd hear me running whilst screaming, off to live in the woods.
Part of why I found it very irresponsible the way the Mythos Preview system card talked about escaping a "secure container" and "secured sandbox" [0], without ever outright saying what it was in the paper. Reading between the lines, it becomes clear that it was a docker-like container or runc or something of that sort, which is A.) not a security focused solution sufficient if one thinks these models are existentially dangerous (if someone in a virology research lab broke SOP and used unsuitable clothing for PPE, I'd view that equally critically) and B.) lead to a lot of attention and concerns as without reading between the lines it was easy to conclude that they were talking about an actual hypervisor escape, which is on a very different level and which Mythos Preview most likely would have failed at considering this line [1]. Also raises the question why their regular "secured sandbox" wasn't "properly configured with modern patches" when Mythos Preview 1 was for a while to dangerous to release...
[0] https://www-cdn.anthropic.com/8b8380204f74670be75e81c820ca8d...
[1] "In addition, in a more challenging sandbox evaluation, it failed to find any novel exploits in a properly configured sandbox with modern patches."