* Posts by gwd

8 publicly visible posts • joined 12 May 2016

Xen warns of nine embargo-worthy bugs

gwd

Moving to KVM because of Xen's XSAs...

Moving from Xen to KVM because we announce security vulnerabilities is like moving from a western country with a free press to China or Iran because of all the bad things you hear about the government. KVM doesn't have a security response process; you may not *ever* find out about vulnerabilities discovered in KVM, and if you're a cloud provider you certainly won't be told about them two weeks before the public announcement. On the other hand, every Xen user can know that in two weeks there will be security updates they should consider applying.

BTW Linode's performance numbers are misleading; instead of comparing 64-bit KVM guests to 64-bit Xen HVM guests (which use hardware virtualization support), they compare 64-bit KVM guests to 64-bit Xen PV guests. 64-bit PV guests on Xen have known performance limitations because AMD removed the segmentation limits (which is what Xen used to make 32-bit guests really fast before hardware virtualization support was available).

Xen Project wants permission to reveal fewer vulnerabilities

gwd

Re: Please stop this ill informed and click bait 'journalism'

FWIW Simon, most of us in the XenProject thought the story itself was unbiased and informative, and we appreciate the "signal boost" to get more people to weigh in on the discussion.

gwd

It's funny that you go on about how transparency won't hurt you, and then point to the list of disclosed vulnerabilities as evidence that you should "stay the hell away from Xen".

Transparency about vulnerabilities actually has a massive cost for any software project, for exactly that reason: people assume that if they don't know about vulnerabilities that there aren't any. So the project which is least transparent will be *perceived* as being more secure, and the project that is the most transparent is *perceived* as being less secure.

The Xen project is one of the few projects which is brave enough to be transparent about our vulnerabilities. The reason you don't see a long list of KVM, Hyper-V, or VMWare vulnerabilities isn't that they don't exist; they do. It's that they don't have the same level of reporting as Xen. We know it affects our reputation, but we think our users' security is actually more important. But most projects look at comments like yours and say, "There's no way we're going to be that transparent." Your attitude actually makes transparency much less attractive to projects, which in turn makes your own security worse.

The proposal we're asking feedback for isn't going to affect the vast majority of vulnerabilities. Late last year we had a bug in the handling of the PSE bit on a 4th-level pagetable (XSA-176). We looked at the code of Linux, NetBSD, FreeBSD, and OpenBSD, as well as the behavior of Windows, and none of them ever set that bit (and so wouldn't be vulnerable). But we issued an advisory anyway to be on the safe side. We've had other similar bugs since. The question we're asking our community is, "Do you want us to issue advisories like that, where nobody actually seems to be affected?"

Good luck getting that kind of consideration from any other hypervisor.

gwd

Re: The real reason

"This basically says that if they can't think of a way of exploiting a bug, then don't worry about it."

No. If you read the full text under number 4, it goes into more detail about what this is about. XSA-176 was a bug in the way L4 pagetable PSE bits were handled. But when we looked, there wasn't a single operating system (Linux, *BSD, Windows, &c) that used the L4 PSE bits -- so nobody was actually vulnerable. We issued an advisory anyway, because the policy wasn't clear and we wanted to err on the safe side.

This is basically us saying to the community, "OK, do you want us to issue advisories like that, or shall we not bother you with them?"

"If this goes through, I wonder if anybody would reconsider their use of Xen based cloud solutions?"

Or, they could, you know, go and ask for the policy to be different. The blog post is a request for people's opinions, not a diktat. Even the proposed change itself says, "These guidelines are not meant to be set in stone; if they do not fit your needs as a user, please raise the issue on xen-devel." So if this passes as-is and you want to come change it later, you're still encouraged to come and ask. Good luck getting that kind of an offer from Microsoft or VMWare, or from KVM (which doesn't issue advisories of any type).

gwd

Re: Yet another reason to

KVM has a much simpler advisory policy: They don't issue any advisories at all. If you're a cloud provider, you get to find out about security issues in KVM by watching the morning news. Or by paying RedHat. Or by looking at every single commit that goes in upstream. But in any case you don't hear before it's public, so you better hope you notice before the bad guys notice.

With Xen, any cloud provider can put their e-mail address on a list and hear about vulnerabilities two weeks before they're publicly disclosed, so you can patch your systems before the world at large knows about it. And you don't pay a dime. You won't get that from any other hypervisor.

Hypervisor security ero-Xen: How guest VMs can hijack host servers

gwd

Illusion of security

The reason you don't hear about KVM vulnerabilities is there's no good way to hear about them. They're usually not announced anywhere publicly. Xen, on the other hand, have an official process whereby you can get e-mail notifications as soon as the vulnerability is discovered and fixed; and if you're a public cloud provider, you can get notification two weeks beforehand, so you can patch your systems before the world knows about it.

So if what you want is the illusion of security, because you just don't hear about the bugs, by all means go with KVM. But if what you want is to be able to actually fix your bugs as soon as possible, go with Xen.

Xen says new patch is 'simple and crude' and warns against using it

gwd

Clarification

What the warning means is that the patch is targeted *only* for deployment within a Xen system; and 1) probably will not be acceptable as-is in the core qemu project ("may not be appropriate for adoption upstream"), and 2) may not actually fix the problem if you're using QEMU outside of a normal Xen system -- for instance, in KVM, or in your own virtualization system ("...or in other contexts").

In other words, this patch is a hack -- a safe and effective one for Xen, but not a long-term solution. Normally we would always try to provide a proper fix, but in this case a proper fix would require changes to the interface, which can't be done effectively in a security update.

The text you quote is a bit unclear; it's difficult sometimes to get every detail just right when you're under time pressure and focusing on trying to get everything else right.

Xen 4.7 ship date slips

gwd

Clarification

Just FYI, both of those dates (the release date and the test day) are estimates. The release day is a very rough guess based on past experience, but particular release times may take weeks less or more. We have test days until the release happens; *if* we aren't ready to ship on the 3rd, we'll have a test day that day. If we are, we won't.