41–50 of 97 posts
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.
Earlier quoted context omitted.
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…
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, when the issue escaped previous analysis, audits and tests? Such process improvement knowledge is possibly more valuable to the worldwide technical community than any point fix.
Heartbleed was discovered by an external party, but this issue which affects the data of millions of users was found by the originating open-source project. Kudos to Jan for finding this cross-domain escalation.
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…
(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.
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.)
Earlier quoted context omitted.
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
Earlier quoted context omitted.
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…
Its called arm64... the first new modern RISC design for a long time.
Earlier quoted context omitted.
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 t…
It might well be fugly but it works . That's the key point. I'm sure Intel (or anyone else), if they could develop x86 again from scratch, and with the benefit of hindsight, would create a much nicer mechanism. But that's just speculation and wishful thinking.
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_TEMPERATURE_TARGET (to calculate CPU temperatures); and MSR_TURBO_RATIO_LIMIT and MSR_TURBO_RATIO_LIMIT1 (to see turbo ratios).
I use them in the showboost, cputemp, and cpuhot MSR-based tools: https://github.com/brendangregg/msr-cloud-tools
Earlier quoted context omitted.
It might well be fugly but it works . That's the key point. I'm sure Intel (or anyone else), if they could develop x86 again from scratch, and with the benefit of hindsight, would create a much nicer mechanism. But that's just speculation and wishful thinking.
In the age of high level languages and compilers, that's exactly what they should have done, possible twice by now.