Slashdot Mirror

I'm not quite sure what you mean by "VT" -- do you mean Intel's VT-x?

It's probably best to let the Xen folks explain far better than I could hope to.

Quemu has their own explanation (and I think KVM is included in the explanation)

I get the feeling that the virtualization instructions (VT-x, AMD-V, and whatever the equivalents are on s390, ARM, and POWER) aren't really involved with either Spectre or Meltdown.

I wonder about SPARC, but given Oracle & Fujitsu appear to be killing SPARC... it probably doesn't matter.

There's a pretty good summary in the XenProject Security Advisory:

Processors give the illusion of a sequence of instructions executed one-by-one. However, in order to most efficiently use cpu resources, modern superscalar processors actually begin executing many instructions in parallel. In cases where instructions depend on the result of previous instructions or checks which have not yet completed, execution happens based on guesses about what the outcome will be. If the guess is correct, execution has been sped up. If the guess is incorrect, partially-executed instructions are cancelled and architectural state changes (to registers, memory, and so on) reverted; but the whole process is no slower than if no guess had been made at all. This is sometimes called "speculative execution".

Unfortunately, although architectural state is rolled back, there are other side effects, such as changes to TLB or cache state, which are not rolled back. These side effects can subsequently be detected by an attacker to determine information about what happened during the speculative execution phase. If an attacker can cause speculative execution to access sensitive memory areas, they may be able to infer what that sensitive memory contained.

Furthermore, these guesses can often be 'poisoned', such that attacker can cause logic to reliably 'guess' the way the attacker chooses. This advisory discusses three ways to cause speculative execution to access sensitive memory areas (named here according to the discoverer's naming scheme):

SP1, "Bounds-check bypass": Poison the branch predictor, such that operating system or hypervisor code is speculatively executed past boundary and security checks. This would allow an attacker to, for instance, cause speculative code in the normal hypercall / emulation path to execute with wild array indexes.

SP2, "Branch Target Injection": Poison the branch predictor. Well-abstracted code often involves calling function pointers via indirect branches; reading these function pointers may involve a (slow) memory access, so the CPU attempts to guess where indirect branches will lead. Poisoning this enables an attacker to speculatively branch to any code that exists in the hypervisor.

SP3, "Rogue Data Load": On some processors, certain pagetable permission checks only happen when the instruction is retired; effectively meaning that speculative execution is not subject to pagetable permission checks. On such processors, an attacker can speculatively execute arbitrary code in userspace with, effectively, the highest privilege level.

The "some processors" for SP3 means Intel.

The first link is a description of XSA-148, which was published last October, not XSA-182.

OTOH, Xen has long touted its security focus and has a really tiny attack surface so I'm happy to be using that in Qubes OS as well.

Excuse me? Xen had more than 100 security alerts in 2015, some extremely severe.

And Xen is based on qemu, which has been proved to be fairly insecure in its own right.

Using Qubes OS, which is based on Xen, which is based on qemu is... How to put it mildly? Maybe not the best idea if you are security conscious.

In the words of Theo De Raadt: "You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes."

I agree with him. It's turtles all the way down.

OTOH, OpenBSD's kernel is about 10X the size of Xen (where the BSD mantra of 'correctness' has a much tighter focus). As isolation mechanisms go, I trust Xen before any monolithic kernel. The upshot is that Xen also gives me the rich features (incl. drivers) of Linux and Windows.

Awwwww, you are so cute. You trust Xen more than kernel xyz? Really?

First of all, please read this.
Then take a look at this.

There are, let's see... right now, 35 CVEs assigned to the Xen project, in 2015 alone? 40 CVEs in 2014?

Compare and contrast with the number of CVEs published for OpenBSD. And the number of patches available for the latest version (5.8) of OpenBSD.. Here is a hint: 99% of these patches do not imply your machine is going to be ''owned'' by someone exploiting the bugs found. Yes, even the OpenSMTPD patches are pretty mild.

You can keep your Qubes OS, thank you very much, I'll stick to OpenBSD, despite all its defaults and warts.

Words of wisdom to meditate:

You've been smoking something really mind altering, and I think you should share it.

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 write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.

(Source.)

Say what you will of this guy, he has got a point. Virtualization is great, but not for security. Period.

That may be the case for cloud deployment. However, there are other very important areas that PVs are being used. For example: qubes, a security focused Linux distribution https://www.qubes-os.org/.

In addition, there is actually a full spectrum between PV and HVM: http://wiki.xen.org/wiki/Xen_P.... Very few use straight HVM, generally it is HVM + PV Drivers. Linux on Xen ends up using PVHVM. The sweet spot for Open Sources OS under Xen is PVH.

PV and HVM are not mutually exclusive. The basic idea of having a modified, "virtualization-aware" guest-os (a.k.a PV) is a good one and results in better performance. Hardware Virtualization often simplifies the implementation of both the hypervisor and PV on the guest, but does not obviate the need for PV. Using both in tandem can result in even greater performance gains. http://wiki.xen.org/wiki/PV_on...

Link to the actual Xen Advisory.
http://xenbits.xen.org/xsa/adv...

You could always run only the non-shitty code outside the sandbox.

Good luck with that. Particularly, with the part of figuring out which software is good enough to not require a sandbox. And that's before considering the bugs your sandbox has.

Wow, thanks for answering my rant and especially the bit about hardware modding an nvidia card. How silly.

No problem, I always try to follow up on posts in case there are questions or anything else, even when I post anonymously here. Not much point with logging in since I comment rarely; usually everyone else covers any useful input I'd make before it even hits my RSS reader, so I just lurk and anon-post here. On SoylentNews I actually comment enough to bother being logged in (as Marand), because there aren't as many people contributing already, so I'm more likely to have something to say that won't be redundant.

This page on the Xen wiki has info about hardware that works, as well as some information on what cards need modification. It also has some references such as this one detailing the sort of work required. The actual modification doesn't seem too bad, but the fact that it's needed at all is bullshit. Hell, I'm not even sure what will happen if you try to use the cards for dom-0 (host) while using an AMD or older nvidia card on a guest.

Something else I learned while researching this is that nvidia seems to be deliberately crippling the hardware at the driver level if it thinks you're not using a quadro. I found where this guy went from a 200 series to a 400 series gtx and noticed a massive performance drop on certain operations. He even re-implemented the operations with shaders and the performance difference evaporated, which makes it sound like deliberately gimping of certain GL calls that are used more in non-gaming apps, to sell Quadros.

Also, it seems I was mistaken about the 400 series. I thought I saw before that the 400s would work fine, but the Xen page says they need modding as well. I know my gtx 260 should work on a guest OS, but that's a hell of a downgrade. If/when I try I'll just have to pick up an AMD card I guess.

I've been using nvidia GPUs since the '90s because their drvers always worked well, especially in Linux, but lately I've been finding a lot of reasons to look elsewhere. I hate that, but I'm not going to tie myself to a brand if they're going to go out of their way to make it harder for me to use. Same reason I tend to use AMD processors; it's far easier to find an AMD cpu+mobo that works with all the virt stuff you want.

On another note, H264 streaming of a game from Windows VM to display on the linux desktop would be a way to do the reverse. So you keep the linux desktop. The encoding is done real time by a dedicated unit on the GPU.. and that feature is especially supported on Geforce 600 and 700 series!, i.e. the generation past 400 series. So that's why it's disabled (though there's some level fo consumer support for this if you use a separate computer)

Good point; wasn't that supposed to be a selling point of that SHIELD thing nvidia was pushing? Plus Steam does something similar now and has a Linux client. It might actually be easier to run a second Windows machine with a kvm switch and then stream it to Steam running on Linux, now that the Linux client got support for it.

The pro is that it's likely easier to set up, the con is that you have to duplicate your hardware unless you don't do anything cpu/gpu intensive on the Linux side, in which case you could just have a trash-box for the regular desktop.

Thinking about it, I believe I'm still inclined to go for passthrough instead. I could set up a kvm switch and hook one monitor up to both displays, and just switch that monitor over when I want to play a game, or something like that.

As a side rant, years ago I thought the port of KDE to Windows meant we'd be able to run the KDE desktop on Windows but no it was

Xen introduced Mini-OS years ago. The question is: how much functionality that the kernel and a fat libc commonly provides, does the application need. Boot times are not really the issue anymore; look at systemd, everything is booted within 2s.

So what exactly is the bug?

It's complicated, which is why so many systems missed it. I did a write-up here with the gory details.

In short, the instruction is executed by the OS to return to user mode. Under certain conditions, this may throw a general protection fault. In AMD this fault happens in user mode. Happening in user mode is safe, so many OSes, designing to the AMD spec and assuming Intel's was the same, weren't checking boundary conditions to make sure that what the user was giving it was OK. But in Intel, the fault happens in privileged mode, with OS privileges but a guest stack pointer. So if the OS doesn't check for boundary conditions (and most didn't), the guest can set the stack pointer anywhere in OS memory and cause the fault handler scribble over it.

So what was the vulnerability? It has to do with a subtle difference in the way in which Intel processors implement error handling in their version of AMD's SYSRET instruction. The SYSRET instruction is part of the x86-64 standard defined by AMD. If an operating system is written according to AMD's spec, but run on Intel hardware, the difference in implementation can be exploited by an attacker to write to arbitrary addresses in the operating system's memory.

A little note there offers further anecdotal "proof" about the robustness of OpenBSD:

It seems that 64-bit versions of NetBSD, FreeBSD, and Microsoft Windows 7 were all vulnerable; Apple OSX may be vulnerable as well. OpenBSD and Linux were not vulnerable. Linux actually fixed the bug in 2006, with CVE-2006-0744.

Other VMs had source leaks, too.

Xen had a source leak.
Virtualbox had a source leak.
Even KVM had a source leak.

These VM people better get their act together!

Yes. http://wiki.xen.org/xenwiki/Remus

More examples:

Coverity

VMWare

Xen

Then again, the work I did for my thesis never made it past "research prototype". Papers are the "coin of the realm" in academia. There's a very long way between "proof of concept that runs well enough to take measurements and publish" and "something I can sell to someone", and there are no papers in between. That leaves entrepreneurs, or departments / people who do it just out of the goodness of their hearts.

I've got a good heart I think, but nowhere near good enough to spend all day at work coding, and then come home and code some more. :-)

Unlimited cpus, unlimited cores, unlimited RAM.

That wasn't always the case. I suspect someone came along and informed them that their software is open-source.

This why Xen PDF might explain it well. Under Xen, guests are running inside the host operating system. In Xen, the hypervisor starts a special Linux kernel (the dom0) that will only take care of drivers for the guests. The design is really different, and has different features. For example, in Xen, you can have your dom0 to run on 2 cores, leaving the rest for the guests (I'm not sure that is possible in KVM), and if you want to avoid any possible CPU starvation, you can even have the guests to not use the cores that the dom0 is using. The CPU scheduler is also very different (and there's not only one available...).

It's mentioned on the Xen4.0 wiki page since that's when the feature was developed. http://wiki.xen.org/xenwiki/Xen4.0 . I think it was originally submitted by Novell developers, who wrote it for SLES11. Later Jeremy (pvops kernel maintainer) submitted it for upstream kernel inclusion, and it got included to upstream Linux in 2.6.36. It's also included in xen.git xen/stable-2.6.32.x branch. I've tested it myself, and all you need to do is to resize the LVM volume in dom0, and domU will detect the size change.

Great post! Many people don't seem to realize a lot has changed in the Xen-land during the last couple of years.. Xen dom0 support is now included in the upstream Linux kernel, and Xen developers are at the moment actively working on upstreaming for example qemu-xen to upstream Qemu. And for people who don't want to "do-it-yourself" there's Xen Cloud Platform (XCP) available.. opensource dedicated virtualization platform shipped as installable ISO image. http://xen.org/products/cloudxen.html .

Actually Xen dom0 support *IS* already in mainline upstream Linux kernel as of 2.6.37 ! Some xen backend drivers are still missing from upstream kernel, but upcoming Linux 2.6.39 includes xen-netback backend driver, and xen-blkback driver is planned for 2.6.40. http://blog.xen.org/index.php/2011/01/14/linux-2-6-37-first-upstream-linux-kernel-to-work-as-dom0/ The pvops framework was merged to Linux 2.6.24 a couple of years ago, and Xen pvops domU support was first usable in Linux 2.6.26. So Xen support has been in upstream Linux kernel for 12 major kernel releases already! Also Redhat RHEL6 runs as Xen VM, both PV and HVM, just as pretty much any distro does nowadays. Upcoming Fedora 15 has a Xen dom0 capable kernel, and it is expected that Fedora 16 will have fully featured Xen dom0 support out-of-the-box (including all the backend drivers that are being upstreamed atm).

The important features right now are manageability - is there a pretty GUI to show the managers? A programmable, easily scriptable API?

There is a sa lighweight API called LIBXENLIGHT with a toolstack called XL. If you are looking for a GUI manager the way to go is to use XCP which includes a more powerful toolstack. XCP 1.0 has not caught up with Xen 4.1 yet,but the next release is planned to as far as I know. In any case, there are lots of management tools forXCP which you can pick from. See XCP_Projects

I don't know what GP was talking about wrt XenServer. XenServer is a great piece of software, and getting better all the time; the free-as-in-beer version is very fully featured, missing only high-end features like automatic fail-over and disaster recovery. You can still create pools of VMs using shared storage, and there are no limits on the number of VMs, amount of memory, amount of virtual cpus, or anything like that. And if you prefer an "open" distribution, you can use the Xen Cloud Project, which is very similar to XenServer, but designed to be community-developed (and thus completely free-as-in-speech as well).

As a developer who joined XenSource and now works for Citrix, I have to say they did a really good job of not screwing up the acquisition. Even though all of the XenSource options vested some time ago, a large percentage of the core developers still work for Citrix, and show no signs of leaving any time soon. So the "Big corp bought something cool and screwed it up" narrative just doesn't fit here.

The underlying features aren't really the important point - they haven't been for some time and that isn't going to change with this release. The important features right now are manageability - is there a pretty GUI to show the managers? A programmable, easily scriptable API?

Consider the Linux kernel from the criticisms you've just made. Does Linus's tree have important features for manageability? Does it have a pretty GUI to show managers? Is it programmable and easily scriptable? The answer is, of course, no; management, GUI, scripts & come from other projects built on top of the Linux Kernel.

The same is true of Xen. The core Xen project is about operating-system-level functionality, just like Linux is. It is, if you will the engine; but what most people want is a car. The scriptable engines, GUI, management tools, and so on are of a completely different type of programming than OS programming, and should be separate projects.

And these projects exist. XenServer is such a system that includes everything that you describe; and the free-as-in-beer version is very powerful. For those wanting an open system, the Xen Cloud Project is a community-oriented version with feature parity, having been based on the same codebase. Additionally, there are people working on porting libvirt bindings to Xen 4.1, so that any management and GUI software that uses libvirt as a backend to manage KVM can also manage Xen.

I appreciate they probably had some QA to do in order to release this puppy and it took a while, but I loaded Evince, un-installed flash and called it a day. If you can't see it on youtube using their HTML 5 beta then that's a real good time to boot up Linux even if it's just in Xen or Oracle/Sun Virtualbox running on Windows. It works just fine for web browsing and less zero day exploits.

This has changed pretty much lately. A lot of new documentation has been written to the wiki, for example: http://wiki.xensource.com/xenwiki/XenCommonProblems has a lot of stuff and links to other new documentation pages. Have you heard of XCP (Xen Cloud Platform, http://www.xen.org/products/cloudxen.html)? It's a full "Xen distribution" featuring install CD, including everything needed for multi-host/pool management. No need to install custom kernels or anything. You can use OpenXenCenter (http://www.openxencenter.com/) to manage it, if you need a GUI tool.

Did you try XCP (Xen Cloud Platform, http://www.xen.org/products/cloudxen.html) ? XCP 0.5 is coming out in June.. you can manage it using OpenXenCenter (http://www.openxencenter.com). Basicly XCP is XenServer opensourced and developer further..

Some comments.. Xen hypervisor (xen.gz) is not meant to be integrated to Linux kernel. Xen is designed to be a separate piece of software. Xen is a secure, type-1 baremetal hypervisor, not a module for Linux. Xen dom0 ("service console") can be Linux, NetBSD or OpenSolaris. Most people use Linux as Xen dom0. When Linux is used as dom0 it needs to be able to run as Xen dom0 (obviously) - and this is where some people have had pain. For a long time the official Xen dom0 kernel patches were only available for Linux 2.6.18. This was difficult for many people and caused some distros to drop Xen dom0 kernel support because they couldn't affort porting the patches to newer kernels themselves. Today the situation is different. Xen developers are actively working on rewriting the Xen dom0 patches based on the (already existing) upstream pvops framework. pvops has been in the upstream Linux kernel since 2.6.24. Xen pvops dom0 patches are available today for the long-term maintained 2.6.32 kernel, and also for 2.6.31, 2.6.33 and 2.6.34. Novell has also forward-ported the old/traditional Xenlinux patches from 2.6.18 to first 2.6.27 and also to 2.6.31, 2.6.32 and 2.6.33. So there are many options today. For more information about the various Xen dom0 kernels see: http://wiki.xensource.com/xenwiki/XenDom0Kernels Also xen.org offers XCP (Xen Cloud Platform) which is a full platform, including installation CD and multi-host/pool management. If you use XCP you don't need to install custom kernels or anything - you get all included in the XCP bundle. More information about XCP: http://www.xen.org/products/cloudxen.html

Xen does.

I saw a demo by Samsung a while back of their ARM port of Xen running multiple operating systems on a mobile phone. Not sure what the status of the technology is now, but they had some pretty nice ideas with the driver model and were talking about live-migrating your VM from your phone to your TV when you got home.

We took our server estate down by a factor of 20 using modern virtualization hardware appliances and hypervisors. Thats right not 10x fewer servers, but 20x. With the right combination of investment in quality shared storage, dedicated virtualization appliances, and the skills to make them work, today our cooling, power, and rack space bills arent worth worrying about.

We are rarely at the cutting edge of technology, but if we can do it, you can.

In order to increase the relevance of this book review to the slashdot readership, it would be helpful to include in the summary a definition of what Xen (or the book's technological focus) is. I skimmed the book review and still couldn't find a definition of Xen- I wanted to know if it was a free, open source virtual machine emulator. It is. I am not dissing this review. Just trying to provide feedback to this reviewer so the next review can be written to draw more people into reading and learning about the subject of the book.

Seth

But isn't xen a more mature FOSS solution than virtualbox? not to mention xen is true FOSS and not some half proprietary software that business have to pay for, vs a feature stripped 'gpled version...'