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

XSA-108 Advisory

xenbits.xen.org

Post reply on HN
Print view View original

51–60 of 97 posts

Re: XSA-108 Advisory

#51

Post by hobbes300 »

joosters wrote: post #14
sudowhodoido wrote: post #10

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…

There is a general assumption amongst virtualised environment administrators that guests are securely separated. And yes, more code to run means more vulnerabilities.

Re: XSA-108 Advisory

#52

Post by pjungwir »

I had "dedicated" AWS instances that were rebooted. A dedicated instance means there is only one guest per box, right? So I'm curious why those had to be rebooted if there is no network-facing vector to this vulnerability. I guess because we could have read from the hypervisor's memory?

Re: XSA-108 Advisory

#53

Post by zorpner »

amluto wrote: post #44
zorpner wrote: post #18

Earlier quoted context omitted.

(Compared to, running the same software on the same hardware using a single OS). I don't think so. If you had been running an OpenBSD instance on hardware as a single OS, you would not be vulnerable to having your system's memory read by this hypervisor bug. So... yes.

This is nonsense. A single OpenBSD kernel on bare metal can do whatever it pleases. A Linux kernel on Xen HVM could, due to this bug, do slightly more than it ought to have been able to do. (In this sense, the LLDT bug was worse.)

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.

Re: XSA-108 Advisory

#54

Post by mbreese »

Someone1234 wrote: post #33
trekkin wrote: post #31

Earlier quoted context omitted.

I implement high-performance software systems in C++ as my day job. The software has to compile and run on Linux, Solaris, and AIX. The same code is 2x slower on AIX (Power) and 3x-5x slower on Solaris (Sparc) than on Linux (x86). So say whatever you want about theoretical differences in architectures, but in the real world Sparc and Power systems are absolutely not competitive, both on price (absolute $$, and per CP…

That's just a circular way of saying "x86 is more popular, therefore better." Which doesn't address the person aboves' point that x86 is inferior in terms of its design. Of course x86 is going to be faster per dollar spent. One is mass market (x86-64) and the other two are hugely niche (Sparc and Power). Plus the Linux kernel has by far the most human-hours spent on its development relative to every other operating s…

It's not just "x86 is more popular, therefore better." It's that the performance of x86 was better than SPARC or Power. Regardless of the cost of the chip, performance is what is really important here. In some instances, performance per watt is more important, but either way... it's performance that's key, not market forces driving cost savings.

I haven't had much experience with SPARC, but I've done some work on Power systems (long ago). Back then (10-ish years ago), Power chips were more powerful than their x86 contemporaries. But at some point, that relationship switched.

However, I wonder how much of this is the chip, and how much is the tooling. Its been awhile since I've needed to think about C/C++ compiling, but from what I remember, the Intel compiler produced (slightly) faster binaries than gcc. Now this is where popularity could prove to be decisive... if the compiler that the OP uses works for x86, SPARC, and Power, how much do you suspect each of those architectures has been optimized? Even if the non-x86 chip itself is capable of running faster than x86, if the toolchain isn't similarly optimized, they could end up having worse performance.

Re: XSA-108 Advisory

#55

Post by tptacek »

peterwwillis wrote: post #45
sudowhodoido wrote: post #28

Earlier quoted context omitted.

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

He's just very dramatically pointing out that, oh, there are some changes we now need to account for, and Intel didn't tell us poor open source developers about them, and that's (supposedly) totally unreasonable. Besides the fact that Intel does not owe De Raadt anything (other software makers pay a hefty sum to be partners, while OpenBSD developers insult anyone who doesn't give them free shit), these bugs are a giv…

No, you're moving the goalposts. DeRaadt pointed out that x86 "barely" has a working paging system. A commenter on HN said there was no basis for that statement, that he was picking on something that wasn't broken, that it was just FUD. It was not FUD. That claim has been refuted.

Re: XSA-108 Advisory

#56

Post by timoth »

danielweber wrote: post #19
ukandy wrote: post #8

Earlier quoted context omitted.

Pre-disclosure list is at the bottom of this page.. http://www.xenproject.org/security-policy.html

Huh, I have a tiny machine at one of those smaller places, and they are on the list. Good to know the smaller players can build up a reputation for embargoing, too.

Interesting that over half of the companies on the list were added within the last week, if the dates in the page changelog accurately reflect when they were added. If so, perhaps they all suddenly bundled in so they could find out what the embargoed vuln. was.

Re: XSA-108 Advisory

#57

Post by mzs »

brendangregg wrote: post #48

I have to wonder if my recent blog post, "The MSRs of EC2", on September 15th has prompted this discovery: http://www.brendangregg.com/blog/2014-09-15/the-msrs-of-ec2.... . When I posted that, I could find no examples of MSR usage in EC2 or Xen. I haven't checked after the reboot, but I hope the MSRs I'm using can still be accessed: IA32_MPERF and IA32_APERF (to calculate real CPU MHz); IA32_THERM_STATUS and MSR_TEMP…

You should email Jan and ask, I'm curious too.

Re: XSA-108 Advisory

#58

Post by pbsd »

tptacek wrote: post #55
peterwwillis wrote: post #45

Earlier quoted context omitted.

He's just very dramatically pointing out that, oh, there are some changes we now need to account for, and Intel didn't tell us poor open source developers about them, and that's (supposedly) totally unreasonable. Besides the fact that Intel does not owe De Raadt anything (other software makers pay a hefty sum to be partners, while OpenBSD developers insult anyone who doesn't give them free shit), these bugs are a giv…

No, you're moving the goalposts. DeRaadt pointed out that x86 "barely" has a working paging system. A commenter on HN said there was no basis for that statement, that he was picking on something that wasn't broken, that it was just FUD. It was not FUD. That claim has been refuted.

One thing does not follow from the other. Core 2 has had paging bugs, ergo x86 has a barely working paging system => Pentium had the FDIV bug, ergo x86 can't be trusted with arithmetic.

For the claim to be properly refuted, the claimer would have to show systemic problems in x86 paging. I believe such a claim can be made, but it simply wasn't yet.

Re: XSA-108 Advisory

#59

Post by hoov »

pjungwir wrote: post #52

I had "dedicated" AWS instances that were rebooted. A dedicated instance means there is only one guest per box, right? So I'm curious why those had to be rebooted if there is no network-facing vector to this vulnerability. I guess because we could have read from the hypervisor's memory?

I believe that "dedicated" means that it's dedicated to your account. So, there can be more than one guest, but those guests are your EC2 instances.

Re: XSA-108 Advisory

#60

Post by blibble »

joosters wrote: post #14
sudowhodoido wrote: post #10

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…

there have been a few xen hvm issues that allow user processes to bypass the VM kernel's normal memory protections, e.g. http://xenbits.xen.org/xsa/advisory-105.html

so the answer to your question is yes: there have been cases where simply adding the hypervisor introduced a vulnerability .

Post reply on HN