Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel

qubes-os.org

Post reply on HN
Print view View original

61–70 of 104 posts

Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel

#61

Post by tucnak »

systemf_omega wrote: post #52
matherial wrote: post #42

Earlier quoted context omitted.

Being right is not the most important part. If you're right but don't convince anyone, you've made no difference. Theo was right that virtualization is a comparatively shoddy security boundary. At the same time, it's flexible and capable in ways that now define the shape of modern IT. Could we have replicated that by other means? If yes, then it's on Theo and other knee-jerk critics that they never proposed a better…

LLM slop account. Admittedly this one was harder to spot.

Oh shit, you're right!

Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel

#64

Post by matherial »

systemf_omega wrote: post #52
matherial wrote: post #42

Earlier quoted context omitted.

Being right is not the most important part. If you're right but don't convince anyone, you've made no difference. Theo was right that virtualization is a comparatively shoddy security boundary. At the same time, it's flexible and capable in ways that now define the shape of modern IT. Could we have replicated that by other means? If yes, then it's on Theo and other knee-jerk critics that they never proposed a better…

LLM slop account. Admittedly this one was harder to spot.

You're chasing ghosts, son.

Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel

#65

Post by matherial »

tucnak wrote: post #61
systemf_omega wrote: post #52

Earlier quoted context omitted.

LLM slop account. Admittedly this one was harder to spot.

Oh shit, you're right!

They aren't, they're one of the people who latch on longstanding and neutral syntax (em-dashes, "it's not $foo") as a proof of LLM text. I don't blame them because HN has a lot of people trying to pass gen AI stuff as their own, and you need quick heuristics... but I'd encourage people at least do it right. Pay for Pangram or something.

Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel

#66

Post by jervant »

grommz wrote: post #41

The founder Joanna Rutkowska left QubesOS in 2018. All the code involved in this bug was committed by her successor Marek Marczykowski-Górecki. Joanna seems to be a genuine good guy, she once wrote a paper titled "Intel x86 considered harmful". That's why Huawei and the Chinese government aren't even trying any more to make western CPU architectures secure, it's a hopeless cause.

[flagged]

Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel

#67

Post by pixl97 »

matherial wrote: post #65
tucnak wrote: post #61

Earlier quoted context omitted.

Oh shit, you're right!

They aren't, they're one of the people who latch on longstanding and neutral syntax (em-dashes, "it's not $foo") as a proof of LLM text. I don't blame them because HN has a lot of people trying to pass gen AI stuff as their own, and you need quick heuristics... but I'd encourage people at least do it right. Pay for Pangram or something.

Or as the new saying goes

"HN: Professionally identifying 230% of posts from 2017 as LLM generated".

That said Panagram is trash for the opposite reason. Not that some people talked like LLMs before LLMs, but now a lot of people talk like LLMs because of LLMs.

Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel

#69

Post by progval »

artyomsv wrote: post #12
zby wrote: post #6

I am still impressed by QubesOS track and I use it for my dedicated 'financials' laptop. IMHO the thing that is holding back QubesOS is the lack of hardware acceleration for graphics - maybe now when dual monitor setups are getting popular this could be a workaround for the security considerations?

Problem is not that nobody wants to do it, it is that GPU stack is exactly the kind of enormous driver surface Qubes exists to keep away from dom0. Second monitor does not really change that, somebody still has to trust the driver.

The driver could run in a VM and only display applications from that VM or a subset of VMs.

Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel

#70

Post by iugtmkbdfil834 »

Betelbuddy wrote: post #48
iugtmkbdfil834 wrote: post #33

Earlier quoted context omitted.

But, and this is the important part, is he wrong?

This community lives on not understanding that...form over function always...

But is the world a better place with that particular understanding being the norm. Would we, as a whole, be better served if function was what actually mattered? Wouldn't that be nice?
Post reply on HN