5 ms·

So this basically throws the whole premise of QubesOS out the window, it seems. Virtualization is hard.

upofadown 10y ago
Wouldn't the fact that this particular vulnerability has been fixed mean that we have to throw the whole premise of QubesOS back in the window? I'm not really seeing any sort of sandboxing tech on Linux that is significantly tougher than Qubes.
im_down_w_otp 10y ago
It's a little bit easier if you care a lot less about performance.
zitterbewegung 10y ago
No this is a security exploit for one hypervisor. Qubes would still protect you for the most common exploits from your web browser or database . No security system is 100%
00098345 10y ago
Security on bare metal OS is a hard problem. Square or cube that to get an idea of security in virtualization.
deleted 10y ago
[deleted]
jeff_marshall 10y ago
IMO, the premise that hypervisors can have a smaller (thus more assurance-friendly) attack surface relative to a monolithic or microkernel-based operating system is not challenged by any attack against xen. Xen has a very feature-rich interface as far as hypervisors go (hello grant tables!). The interface to the hypervisor on x86_64 can be small while still being performant and functional (EPT and posted interrupts are very nice). That said, I work for a company that sells a hypervisor built on the idea that hypervisors need not be complex to solve real problems. We look at hypercalls that include data structures (even ones as simple as C strings) with great skepticism.
ams6110 10y ago
You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes. Theo de Raadt
- runeks 10y ago
  So because 95% of worldwide software developers write PHP web servers full of security holes, it is not possible for a different group of developer to create a secure interface? None of these web developers ever cared one bit about the security of their app. You can't compare that with someone intending to develop a secure interface. Security doesn't happen by mistake. The value proposition of Xen is that it's a well-defined interface. The host OS kernel takes care of hardware initialization, and Xen becomes an interface on top of this kernel, through which untrusted client applications access hardware resources. So the innovation of Xen is not that it's supposedly bug-free. It's that it separates concerns: not mixing together hardware initialization (Linux) and resource access/isolation for user space code. That alone leaves less room for bugs. The value of Linux is its drivers, not the actual kernel. So let's use Linux for its drivers, rather than as a standard library. The only reason people use, for example, the Linux CPU scheduler, is that it's inextricably tied to the Linux drivers, because no interface exists (all code runs in one huge blob). This is what Xen wants to fix. If the Linux folks concentrated on creating secure driver interfaces, rather than implementing CPU schedulers and memory managers themselves, it would mean that all the other developers of the world could write CPU schedulers, rather than only the select few people who think they know the Linux code base (who still end up producing bugs). An interface is worth so much more than just an implementation of one, because it not only makes access easy for the client, but also makes the creation of new server implementations easy (by having a well-defined protocol/interface to which they must conform).
  - mshook 10y ago
    I don't read it like that. From my point of view it's like saying if you sell virtualization as a way to isolate different OSes + applications for security reasons (compared to cost savings and all associated from using this kind of technology), clearly you better think twice about that. And really, it's pretty much always a selling point when you talk to a marketing rep or your PHB or her/his PHBs.

Wouldn't the fact that this particular vulnerability has been fixed mean that we have to throw the whole premise of QubesOS back in the window? I'm not really seeing any sort of sandboxing tech on Linux that is significantly tougher than Qubes.

im_down_w_otp 10y ago

It's a little bit easier if you care a lot less about performance.

zitterbewegung 10y ago

No this is a security exploit for one hypervisor. Qubes would still protect you for the most common exploits from your web browser or database . No security system is 100%

00098345 10y ago

Security on bare metal OS is a hard problem. Square or cube that to get an idea of security in virtualization.

deleted 10y ago

[deleted]

jeff_marshall 10y ago

IMO, the premise that hypervisors can have a smaller (thus more assurance-friendly) attack surface relative to a monolithic or microkernel-based operating system is not challenged by any attack against xen. Xen has a very feature-rich interface as far as hypervisors go (hello grant tables!). The interface to the hypervisor on x86_64 can be small while still being performant and functional (EPT and posted interrupts are very nice). That said, I work for a company that sells a hypervisor built on the idea that hypervisors need not be complex to solve real problems. We look at hypercalls that include data structures (even ones as simple as C strings) with great skepticism.

ams6110 10y ago

You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes. Theo de Raadt

runeks 10y ago
So because 95% of worldwide software developers write PHP web servers full of security holes, it is not possible for a different group of developer to create a secure interface? None of these web developers ever cared one bit about the security of their app. You can't compare that with someone intending to develop a secure interface. Security doesn't happen by mistake. The value proposition of Xen is that it's a well-defined interface. The host OS kernel takes care of hardware initialization, and Xen becomes an interface on top of this kernel, through which untrusted client applications access hardware resources. So the innovation of Xen is not that it's supposedly bug-free. It's that it separates concerns: not mixing together hardware initialization (Linux) and resource access/isolation for user space code. That alone leaves less room for bugs. The value of Linux is its drivers, not the actual kernel. So let's use Linux for its drivers, rather than as a standard library. The only reason people use, for example, the Linux CPU scheduler, is that it's inextricably tied to the Linux drivers, because no interface exists (all code runs in one huge blob). This is what Xen wants to fix. If the Linux folks concentrated on creating secure driver interfaces, rather than implementing CPU schedulers and memory managers themselves, it would mean that all the other developers of the world could write CPU schedulers, rather than only the select few people who think they know the Linux code base (who still end up producing bugs). An interface is worth so much more than just an implementation of one, because it not only makes access easy for the client, but also makes the creation of new server implementations easy (by having a well-defined protocol/interface to which they must conform).
- mshook 10y ago
  I don't read it like that. From my point of view it's like saying if you sell virtualization as a way to isolate different OSes + applications for security reasons (compared to cost savings and all associated from using this kind of technology), clearly you better think twice about that. And really, it's pretty much always a selling point when you talk to a marketing rep or your PHB or her/his PHBs.