Xen Project Officially Ports Its Hypervisor To Raspberry Pi 4 (theregister.com) 19
The Xen Project has ported its hypervisor to the 64-bit Raspberry Pi 4. The Register reports: The idea to do an official port bubbled up from the Xen community and then reached the desk of George Dunlap, chairman of the Xen Project's Advisory Board. Dunlap mentioned the idea to an acquaintance who works at the Raspberry Pi Foundation, and was told that around 40 percent of Pis are sold to business users rather than hobbyists. With more than 30 million Arm-based Pis sold as of December 2019, and sales running at a brisk 600,000-plus a month in April 2020, according to Pi guy Eben Upton, Dunlap saw an opportunity to continue Xen's drive towards embedded and industrial applications.
Stefano Stabellini, who by day works at FPGA outfit Xilinx, and past Apache Foundation director Roman Shaposhnik took on the task of the port. The pair clocked that the RPi 4's system-on-chip used a regular GIC-400 interrupt controller, which Xen supports out of the box, and thought this was a sign this would, overall, be an easy enough job. That, the duo admitted, was dangerous optimism. Forget the IRQs, there was a whole world of physical and virtual memory addresses to navigate. The pair were "utterly oblivious that we were about to embark on an adventure deep in the belly of the Xen memory allocator and Linux address translation layers," we're told. [The article goes on to explain the hurdles that were ahead of them.]
"Once Linux 5.9 is out, we will have Xen working on RPi4 out of the box," the pair said. [...] Stefano Stabellini told The Register that an official Xen-on-RPi port will make a difference in the Internet-of-Things community, because other Arm development boards are more costly than the Pi, and programmers will gravitate towards a cheaper alternative for prototyping. He also outlined scenarios, such as a single edge device running both a real-time operating system alongside another OS, each dedicated to different tasks but inhabiting the same hardware and enjoying the splendid isolation of a virtual machine rather than sharing an OS as containers. George Dunlap also thinks that an official Xen-on-RPi port could also be of use to home lab builders, or perhaps just give developers a more suitable environment for their side projects than a virtual machine or container on their main machines. Stay tuned to Project EVE's Github page for more details about how to build your own Xen-for-RPi. Hacks to get it up and running should also appear on the Xen project blog.
Stefano Stabellini, who by day works at FPGA outfit Xilinx, and past Apache Foundation director Roman Shaposhnik took on the task of the port. The pair clocked that the RPi 4's system-on-chip used a regular GIC-400 interrupt controller, which Xen supports out of the box, and thought this was a sign this would, overall, be an easy enough job. That, the duo admitted, was dangerous optimism. Forget the IRQs, there was a whole world of physical and virtual memory addresses to navigate. The pair were "utterly oblivious that we were about to embark on an adventure deep in the belly of the Xen memory allocator and Linux address translation layers," we're told. [The article goes on to explain the hurdles that were ahead of them.]
"Once Linux 5.9 is out, we will have Xen working on RPi4 out of the box," the pair said. [...] Stefano Stabellini told The Register that an official Xen-on-RPi port will make a difference in the Internet-of-Things community, because other Arm development boards are more costly than the Pi, and programmers will gravitate towards a cheaper alternative for prototyping. He also outlined scenarios, such as a single edge device running both a real-time operating system alongside another OS, each dedicated to different tasks but inhabiting the same hardware and enjoying the splendid isolation of a virtual machine rather than sharing an OS as containers. George Dunlap also thinks that an official Xen-on-RPi port could also be of use to home lab builders, or perhaps just give developers a more suitable environment for their side projects than a virtual machine or container on their main machines. Stay tuned to Project EVE's Github page for more details about how to build your own Xen-for-RPi. Hacks to get it up and running should also appear on the Xen project blog.
Oh boy (Score:1)
The abstraction layer crowd has found ARM, as if it already wasn't slow enough. Can't wait to run all my software in bloated insecure containers inside a VM.
Comment removed (Score:5, Informative)
Yep, neither abstraction later not insecure (Score:4, Informative)
Indeed. There *is* no abstraction later for most code, it runs natively on the CPU. The IO has to go through the hypervisor, which doesn't slow it significantly because it would otherwise go through a driver. Using virtio, there basically is no driver in the guest, it's just renaming a memory page.
On security, Xen is highly secure for separating guests.
With a few patches to Xen for things like tick count, it can be shown that a program running in Xen can't even *detect* that it's running in a VM, much less escape that VM.
Where there can be a slight loss of security is between toe programs running in the same VM. If you're using VMs, don't run super sensitive code in the same VM as untrusted code that takes input from the internet. The issue there is that with a normal OS, the kernel runs in ring 0 and the applications run in ring 3. Certain important privileged instructions cannot be run in 3, the CPU will only allow the kernel to run them. That's key to securing one program from another, to making sure that an application can't do kernel things like messing with another process. In a VM, the hypervisor has ring 0, so the kernel is ring 3 just like the applications. So you lose the protections provided by the CPU and it's privileged instructions, trusting the hypervisor to handle that instead.
This is great! (Score:2)
Now if only we had enough RAM to make use of it...
On the other hand, instead of running a bunch of VMs, why not just buy a bunch of RPi4's and not be so RAM restricted? It's not like they cost all that much (unless you're going for 8GB or 4GB versions).
Re: (Score:3)
The nice thing about VMs is remote access to the console. If you run stuff in a VM, you can recover an otherwise unbootable system without physical access as long as you don't lose access to the hypervisor (or dom0 in the case of Xen).
Re: (Score:2)
Re: (Score:1)
Re: (Score:3)
insert obligatory "imagine a beowulf cluster of these!"...
Re: (Score:1)
You don't have to imagine it, it has already happened: https://tech.slashdot.org/stor... [slashdot.org]
Re: (Score:2)
For the Pi with 4GB of RAM Docker containers are a better option if you can live without the extra isolation and other benefits of a VM. There are some great IoT stacks based on Docker containers on the Pi.
Re: (Score:2)
Too bad that ship as sailed. We like containers way more than we like VMs.
Advantage over Docker? (Score:2)
Struggling to find many use-cases where this would be an advantage over Docker these days. Docker has been available on the Pi for some time, is even more light-weight (making great use of the Pi's limited memory resources), yet achieves the same real-world level of workload isolationism.
Hell, you can then easily scale up by running k3s.
Re: (Score:2)
Re: (Score:2)
Yeah, I get that. Docker containers aren't always the easiest to debug in and get right. And I work with them every day for my day job!
Re: (Score:2)
Re: (Score:2)
I run containers "at scale" (ie, multiple thousands) for federal government (thank you, Kubernetes and OpenShift!)
In my stack, I try to get rid of VMs and get Docker as close to the metal as possible, because:
* Running a VM layer underneath OpenShift creates two layers that are both trying to shift load. Doesn't make for great load balancing decisions.
* Splitting HW up into VMs adds extra overhead at multiple layers (another docker engine which saps 15% of a core, etc)
So yes, it's perfectly valid to remov
Re: (Score:2)
Re: (Score:2)
You make a good point. But if your workload relies on hardware interrupts and the RTC, then you're probably not running either Docker nor Xen.
Re: (Score:2)
Came here to say this. Raspbian already comes with container architecture since a few years ago.