Live data from Hacker News

XSA-108 Advisory

xenbits.xen.org

21–30 of 97 posts

Re: XSA-108 Advisory

#21

Well looks like Mr De Raadt was right again: 'x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit. You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't writ…

This is just FUD and in the usual insulting De Raadt style of communicating. 'barely has correct page protection' is just a way of saying 'has correct page protection, but I want to be really snotty about it'. So, highlighting a non-problem. No-one is claiming that virtualization makes a system magically completely secure, but do people actually believe that it makes it less secure? (Compared to, running the same sof…

To be fair, that email is from 2007. Did x86 processors have nested page tables back then? If not, he might have been complaining about that.

Re: XSA-108 Advisory

#22
post #11

Interesting that the patch is just one characters difference (applied in two locations) 0x3ff to 0xff

From the patch:

> While the write path change appears to be purely cosmetic (but still gets done here for consistency), the read side mistake permitted accesses beyond the virtual APIC page.

http://xenbits.xen.org/xsa/xsa108.patch

Re: XSA-108 Advisory

#23

Well looks like Mr De Raadt was right again: 'x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit. You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't writ…

This is just FUD and in the usual insulting De Raadt style of communicating. 'barely has correct page protection' is just a way of saying 'has correct page protection, but I want to be really snotty about it'. So, highlighting a non-problem. No-one is claiming that virtualization makes a system magically completely secure, but do people actually believe that it makes it less secure? (Compared to, running the same sof…

> No-one is claiming that virtualization makes a system magically completely secure, but do people actually believe that it makes it less secure?

I believe he was comparing it with jails and other similar technologies, which work at the OS level rather than loading another kernel.

Re: XSA-108 Advisory

#24
post #20

Can somebody please confirm that it is impossible to boot a HVM system on Linode? The hypervisor on my Linode host certainly supports HVM (according to cat /sys/hypervisor/properties/capabilities). The host Xen is 4.1 and therefore vulnerable in the case that another user could be running HV guests.

There is no such thing as an HVM Linode server, all Linodes are PV.

Re: XSA-108 Advisory

#25

Well looks like Mr De Raadt was right again: 'x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit. You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't writ…

This is just FUD and in the usual insulting De Raadt style of communicating. 'barely has correct page protection' is just a way of saying 'has correct page protection, but I want to be really snotty about it'. So, highlighting a non-problem. No-one is claiming that virtualization makes a system magically completely secure, but do people actually believe that it makes it less secure? (Compared to, running the same sof…

Not really. He's right. The memory, paging and protection model for X86 is fugly at best. It's very easy to hang yourself as demonstrated.

You can be as insulting as you like if you compare X86 (and X86-64) to SPARC and POWER which is what I assume he is doing here considering he provides operating systems for multiple architectures. We're talking about an architecture that started with the 8086 and despite changes to the underlying microcode architecture, the front end ISA and system interface is still plagued with poorly designed extensions hacked on.

Regarding virtualization, any sharing of resources, particularly at a hardware level is an attack vector if not implemented correctly. Whether or not it is implemented correctly or is exploitable is merely a matter of time and effort as demonstrated here. That is unless mathematically verified, which it isn't and based on the evolved x86 architecture probably isn't possible so it can't be more secure and is unlikely to be as secure. That leaves only less secure.

Re: XSA-108 Advisory

#26

Well looks like Mr De Raadt was right again: 'x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit. You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't writ…

This is just FUD and in the usual insulting De Raadt style of communicating. 'barely has correct page protection' is just a way of saying 'has correct page protection, but I want to be really snotty about it'. So, highlighting a non-problem. No-one is claiming that virtualization makes a system magically completely secure, but do people actually believe that it makes it less secure? (Compared to, running the same sof…

Didn't deRaadt have to commit OpenBSD workarounds to TLB errata just a couple years back? I don't think he's making things up.

Re: XSA-108 Advisory

#27
post #11

Interesting that the patch is just one characters difference (applied in two locations) 0x3ff to 0xff

Seems to me like they should be using constants. Especially since this implies the 0xff/256 is elsewhere as well: elsewhere a 256 rather than 1024 wide window is being used too

*0xff/255

Simple but potentially dangerous right? :P

Re: XSA-108 Advisory

#28
post #26

Earlier quoted context omitted.

This is just FUD and in the usual insulting De Raadt style of communicating. 'barely has correct page protection' is just a way of saying 'has correct page protection, but I want to be really snotty about it'. So, highlighting a non-problem. No-one is claiming that virtualization makes a system magically completely secure, but do people actually believe that it makes it less secure? (Compared to, running the same sof…

Didn't deRaadt have to commit OpenBSD workarounds to TLB errata just a couple years back? I don't think he's making things up.

Yes. See: http://marc.info/?l=openbsd-misc&m=118296441702631

Re: XSA-108 Advisory

#29
post #21

Earlier quoted context omitted.

This is just FUD and in the usual insulting De Raadt style of communicating. 'barely has correct page protection' is just a way of saying 'has correct page protection, but I want to be really snotty about it'. So, highlighting a non-problem. No-one is claiming that virtualization makes a system magically completely secure, but do people actually believe that it makes it less secure? (Compared to, running the same sof…

To be fair, that email is from 2007. Did x86 processors have nested page tables back then? If not, he might have been complaining about that.

No they didn't have SLAT/EPT then. That came in with the i-series processors. The processors were knee deep in errata and buggy as hell.

As they are now: http://www.intel.co.uk/content/dam/www/public/us/en/document...

Intel don't do a good job of design or engineering really. That's going to sting, I know.

I'd love to see 64 bit SPARC make a comeback TBH. Proper hardware contexts/threads, more registers, a decent MMU etc.

Re: XSA-108 Advisory

#30
post #11

Interesting that the patch is just one characters difference (applied in two locations) 0x3ff to 0xff

Yep, it seems only to change a small memory range. I'm guessing this means this isn't highly exploitable, but contains at least some risk of leaking private information. Can anyone with more experience with this specific APIC stuff comment? Could you get different data each time or only the same small range?
Post reply on HN