Interesting that the patch is just one characters difference (applied in two locations) 0x3ff to 0xff
Deliberate? Coincidence?
It's pretty certain they deliberately changed both instances of the number. How is that even a question?
XSA-108 Advisory
71–80 of 97 posts
Re: XSA-108 Advisory
#72Earlier quoted context omitted.
In the age of high level languages and compilers, that's exactly what they should have done, possible twice by now.
They did. It was called Itanium.
Itanium was a completely different type of architecture, not a rebuild that keeps the same basic form but simplifies.
Re: XSA-108 Advisory
#73Thanks to Jan Beulich, the SUSE Xen maintainer in Germany who is credited with finding this x86 HVM vulnerability. It would be helpful if errata announcements included documentation of the static analysis tools, code review process or automated testing techniques which identified the weakness, along with a postmortem of previous audits of relevant code paths. What made it possible for this issue to be identified now,…
Was http://www.brendangregg.com/blog/2014-09-15/the-msrs-of-ec2.... the reason they were looking?
Re: XSA-108 Advisory
#74Earlier quoted context omitted.
You have an incoherent mental threat model of this. Those two systems are functionally identical to the end user to which they are being sold, but one is vulnerable (in this specific way) to the actions of other customers with the same service provider.
This has nothing to do with threat models and everything to do with usecases that make no sense on OpenBSD. With OpenBSD on bare metal, you are not vulnerable to other users of the same bare metal, because there aren't any. With Linux on bare metal, you are not vulnerable to other users of the same bare metal, because there aren't any. With Linux on Xen, you are reasonably resistant to other users of the same bare me…
Usecases with multiple users on one piece of hardware make no sense? Is there a reason (besides the previous question) you are ignoring the ability to use containers as an alternative to virtualization for all of the perks they provide?
Re: XSA-108 Advisory
#75Thanks to Jan Beulich, the SUSE Xen maintainer in Germany who is credited with finding this x86 HVM vulnerability. It would be helpful if errata announcements included documentation of the static analysis tools, code review process or automated testing techniques which identified the weakness, along with a postmortem of previous audits of relevant code paths. What made it possible for this issue to be identified now,…
Was http://www.brendangregg.com/blog/2014-09-15/the-msrs-of-ec2.... the reason they were looking?
Don't know. A downthread post (https://news.ycombinator.com/item?id=8393911) links to the Dec 2010 Intel patch which introduced the bug. It may have originated with a RedHat KVM patch in June 2009, https://lkml.org/lkml/2009/6/29/205
Re: XSA-108 Advisory
#76Well 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? (Compared to, running the same software on the same hardware using a single OS). I don't think so."
However, common virtualized platforms such as EC2 encourage you to run your whole server setup in an environment where a (possibly malicious) neighbour could be running arbitrary x86 code in an instance on the same physical machine. This is not an attack vector that is remotely possible in the traditional, non-virtualized setup.
Re: XSA-108 Advisory
#77Earlier quoted context omitted.
Every kernel (not named seL4) has vulnerabilities. The question is not whether OpenBSD would have been vulnerable to this specific issue, but whether Xen generally has fewer bugs than the OpenBSD kernel - or, for that matter, the Linux kernel, since the grandparent mentioned a bunch of Linux sandboxing technologies. edit: To be absolutely clear, per the grandparent, I'm assuming an environment where unrelated people…
And if any thinks that the awesome perfection of OpenBSD's authors outweighs the vastly smaller attack surface of something like Xen, I think that they're deluding themselves.
"the vastly smaller attack surface of something like Xen"
Um, citation needed. The exact behaviour of the entire x86 supervisor mode instruction set is not remotely a "small attack surface".
Re: XSA-108 Advisory
#78Earlier 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…
"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 software on the same hardware using a single OS). I don't think so." However, common virtualized platforms such as EC2 encourage you to run your whole server setup in an environment where a (possibly malicious) neighbour could be running arbitr…
They aren't encouraging you, it is being demanded (by you, by everybody). This is how cheap, reliable, redundant computing is offered, and it will always be cheaper than paying for and maintaining entire physical machines.
Re: XSA-108 Advisory
#79Earlier quoted context omitted.
And if any thinks that the awesome perfection of OpenBSD's authors outweighs the vastly smaller attack surface of something like Xen, I think that they're deluding themselves.
"the vastly smaller attack surface of something like Xen" Um, citation needed. The exact behaviour of the entire x86 supervisor mode instruction set is not remotely a "small attack surface".
The attack surface of incorrect use of the admittedly complicated x86 privilege transition and protection mechanisms is shared in its entirety by all x86 operating systems (except, to a limited extent, by those that turn off some of these mechanisms, which AFAIK none do).
Re: XSA-108 Advisory
#80Earlier quoted context omitted.
And if any thinks that the awesome perfection of OpenBSD's authors outweighs the vastly smaller attack surface of something like Xen, I think that they're deluding themselves.
"the vastly smaller attack surface of something like Xen" Um, citation needed. The exact behaviour of the entire x86 supervisor mode instruction set is not remotely a "small attack surface".
Flipside is that with hardware virtualization, a lot of that behavior is protected in hardware which, for whatever reason, seems to be extremely secure in practice. You don't see a lot of erratum-based exploits... the recent SYSRET bug was severe but only counts somewhat ("instruction does something different than what it does on another vendor's processors, and is technically documented to do so" is bad, but it's not like there was some sequence of instructions that would just get you arbitrary memory access without interacting with the hypervisor).