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.
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.
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.
First I heard of Qubes was when Edward Snowden endorsed it
https://www.qubes-os.org/endorsements/
https://xcancel.com/Snowden/status/781493632293605376
QubesOS is really fantastic, I wouldn't consider using anything less today.
Author of the paper here; AMA.
In comparing xen to qubes bulletins does the vastly different user count affect the analysis?
BTW, project summary is here https://www.pwnshow.com/investigations/INV-006/
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?
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.
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."