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

61–70 of 97 posts

Re: XSA-108 Advisory

#61

Post by tptacek »

pbsd wrote: post #58
tptacek wrote: post #55

Earlier quoted context omitted.

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.

You're litigating a different claim than I am. The claim I'm refuting is:

"barely has correct page protection' is just a way of saying 'has correct page protection, but I want to be really snotty about it

I don't have to demonstrate systemic flaws in x86 paging to refute that.

I don't think paging system security is a good basis on which to choose processor architectures. I do sort of agree with Theo's point about virtualization, which really is a petri dish for terrible vulnerabilities. But either way: my point is just that Theo isn't just making things up here.

Re: XSA-108 Advisory

#62

Post by walterbell »

mzs wrote: post #12
alexduros wrote: post #7

interesting link ... from 2010 http://xen.1045712.n5.nabble.com/x2APIC-emulation-for-HVM-gu...

good find: @@ -2189,6 +2190,11 @@ *msr_content = vcpu_vlapic(v)->hw.apic_base_msr; break; + case MSR_IA32_APICBASE_MSR ... MSR_IA32_APICBASE_MSR + 0x3ff: + if ( hvm_x2apic_msr_read(v, msr, msr_content) ) + goto gp_fault; + break; + case MSR_IA32_CR_PAT: *msr_content = v->arch.hvm_vcpu.pat_cr; break; @@ -2296,6 +2302,11 @@ vlapic_msr_set(vcpu_vlapic(v), msr_content); break; + case MSR_IA32_APICBASE_MSR ... MSR_IA32_AP…

Is this from the Intel Xen+KVM team, crediting the patch to a member of the RedHat KVM team?

Since KVM isn't vulnerable to this cross-domain issue, it may be useful to compare with the equivalent code in KVM and/or Linux.

Re: XSA-108 Advisory

#63

Post by comex »

hobbes300 wrote: post #51
joosters wrote: post #14

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…

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

From the perspective of a public cloud host etc., it's not more code to run; any fault of the guest kernel is not their problem, so they likely have less code to run compared to jail-based solutions that run a full Unix kernel in ring 0.

Re: XSA-108 Advisory

#64

Post by pjungwir »

hoov wrote: post #59
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.

Ah, thanks for the clarification! I guess that still means they were rebooting our machines in case the malicious actor was us. :-)

Re: XSA-108 Advisory

#65

Post by comex »

zorpner wrote: post #18
joosters wrote: post #14

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.

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 are running software on the same hardware, either using their own kernel under Xen or user processes under jails.

Re: XSA-108 Advisory

#68

Post by h43k3r »

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…

Can somebody point me to beginner articles on what is wrong with x86 ?

PS- I have only done a undergraduate level course on computer architecture

Re: XSA-108 Advisory

#69

Post by amluto »

zorpner wrote: post #53
amluto wrote: post #44

Earlier quoted context omitted.

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.

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 metal (and XSA-108 wasn't even all that severe).

With OpenBSD on Xen... oh, wait.

Re: XSA-108 Advisory

#70

Post by amluto »

comex wrote: post #65
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.

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.
Post reply on HN