SoylentNews is people
SoylentNews
from the where-have-we-HURD-of-this-before? dept.
Specialised computer software components to improve the security, speed and scale of data processing in cloud computing are being developed by a University of Cambridge spin-out company. The company, Unikernel Systems, which was formed by staff and postdoctoral researchers at the University Computer Laboratory, has recently been acquired by San-Francisco based software company Docker Inc.
Unikernels are small, potentially transient computer modules specialised to undertake a single task at the point in time when it is needed. Because of their reduced size, they are far more secure than traditional operating systems, and can be started up and shut down quickly and cheaply, providing flexibility and further security.
They are likely to become increasingly used in applications where security and efficiency are vital, such as systems storing personal data and applications for the so-called Internet of Things (IoT) – internet-connected appliances and consumer products.
Researchers at the Computer Laboratory started restructuring VMs into flexible modular components in 2009, as part of the RCUK-funded MirageOS project. These specialised modules – or unikernels - are in effect the opposite of generic VMs. Each one is designed to undertake a single task; they are small, simple and quick, using just enough code to enable the relevant application or process to run (about 4% of a traditional operating system according to one estimate).
The small size of unikernels also lends considerable security advantages, as they present a much smaller 'surface' to malicious attack, and also enable companies to separate out different data processing tasks in order to limit the effects of any security breach that does occur. Given that resource use within the cloud is metered and charged, they also provide considerable cost savings to end users.
http://phys.org/news/2016-01-safer-faster-unikernels.html
[Source]: http://www.cam.ac.uk/research/news/making-operating-systems-safer-and-faster-with-unikernels
(Score: 5, Informative) by TheRaven on Friday January 29 2016, @11:15AM
Unikernels are small, statically linked, VMs that have a single trust domain per VM. The Cambridge implementation uses ocaml and performs whole-program optimisation (and, in particular, specialisation) across the entire instance. For example, if you want to have a DNS server, you'll compile your DNS configuration, the DNS server parts of the program, and the network stack together and get a tiny VM image (well under 1MB) that just contains that parts of the OS that you need and the parts of your program. You can spin up a few thousand instances of it in a couple of seconds across a variety of cloud providers. The same is true for other small server tasks. Because your server is the only thing running in the VM, the start time is barely measurable. In contrast, a typical *NIX VM has to start a load of generic services before it even gets to your code and will then be running things like a scheduler to make sure that the other services are all working correctly and using the MMU to isolate them.
The problem that unikernels are really trying to solve is that people are increasingly treating VMs like processes. Running an instance of Linux (including a bunch of device drivers and services that you won't use), systemd, sshd, and so on just to run nginx is inefficient. You're distributing a load of code that is irrelevant to the task at hand. By creating small, highly specialised programs, you can make far more efficient use of a hypervisor.
Oh, and unikernels also support deployment as OS processes on Linux/*BSD, so you don't have to use a hypervisor if you'd prefer a more conventional OS.
sudo mod me up
(Score: 3, Interesting) by dltaylor on Friday January 29 2016, @11:52AM
I can do, and have done, the same thing with a *BSD or Linux (and, back in the day, AT&T UNIX System 5).
You can build a kernel with no more features than you need (don't need all of the file systems, for example, compile them out, and don't load the modules; the ram disk on linux does not need any storage medium (SCSI, SATA, IDE, ...) for backing store).
Then, create your program as "/sbin/init" (or, for amusement, "/sbin/systemd") , statically linked. it, and only it, will run.
(Score: 4, Interesting) by TheRaven on Friday January 29 2016, @12:24PM
I find your claim that I don't know *nix very well hilarious.
You absolutely can not do the same thing with a conventional *NIX OS. You can create a stripped-down kernel config, and you can make it run a single process, but this is very different from a unikernel. First, you still have the system call layer as your interface. Unless you have a libOS or exokernel, that's where optimisation stops: even if you do link-time optimisation of both userspace and the kernel, the compiler will treat the system call layer as an opaque boundary. It can't, for example, elide copying at that boundary, or inline system calls. Even if your hardware has zero overhead system calls, this still imposes a big performance barrier.
Second, even with your stripped-down kernel config, there are a lot of parts of the kernel that are not separable. Sure, you can compile out filesystems, but have you tried compiling out the VFS layer entirely for something that just needs a block store managed by the userspace process? With the unikernel model, only parts of the OS that are directly used by the equivalent of the userspace process will be linked in and those bits will be specialised for precisely their target uses. Can you compile your favourite *NIX to only include the code for reading from a paravirtualised block device, but not for writing to it?
Third, there are lots of things on a typical *NIX system that are provided by separate processes. If you make your process init, you won't even get working networking unless you copy a load of ifconfig and dhclient, or equivalents into your program. Not so useful for a server. Sure, you can copy all of this code, but the tooling isn't set up for it.
sudo mod me up
(Score: 1) by CHK6 on Friday January 29 2016, @01:22PM
Thank you for a more detailed and further explanation. Would you humor me in answering this simple question, so that I understand better. Are Unikernels the next step in removing the need for underlying operating systems to run an application?
I have been annoyed through my entire career when dealing with applications that I want to use, but needing a host of different operating systems to run them. Could Unikernels free us from the OS? If so, what is best way to start learning how to develop applications for this new style of technologies? (Sorry, couldn't help asking more bonus questions.)
(Score: 3, Interesting) by bzipitidoo on Friday January 29 2016, @04:57PM
Free us from the OS?! That's going back to the 1950s time of "bare iron". They tried to live without an OS, running a batch processing system in which each program was loaded into memory (from punch cards) one at a time, and given total control of the hardware. Was argued that any management code was overhead, and that's true. Problem is, not doing any management wastes a lot more cycles because the hardware does not all run in lockstep, some parts are faster than others. When a program is using the slower parts, the fast parts are idling unless given some other program to run. Another problem is bugs. What if a program gets stuck in an infinite loop, how does a batch processing system break out of this condition? Some can't, it takes human operators to decide that the computer must be stuck, and manually terminate the program possibly by throwing the "big red switch". Others use the crude method of simply cutting programs off after an arbitrary amount of time, which always has the danger of terminating a working program before it was finished. Those problems are what lead computer scientists to accept the overhead of running an OS.
What we do have going on today is massive library bloat. If you want to trim some fat, far better to target libraries than OSes. What's crazy is having lots of duplicate functionality in C libraries, Java libraries, and whatever other programming languages that must have their own libraries. Further duplication occurs because so many libraries are "every man an island", and will have the same low level functionality as one or more other libraries. Consider Boost, the STL, and the Gnome and KDE libraries, and the dozens of other GUI libraries. Then there are obsolete libraries that have to be kept around for backwards compatibility, stuff like stdio and xlib. Microsoft is notorious for churning, papering over problems in libraries by rolling out totally new libraries rather than fixing the bugs, but leaving the old libraries in place, still broken, for the old software that depends on them. The suspicion is that this is somewhat deliberately neglectful, that MS doesn't bother to research better ways because their first priority is profit not quality, and they believe their current methods keep customers more firmly stuck on the upgrade treadmill. Some years ago, the Firefox developers went on a hunt to clean up some library duplication, and decided to kick out the MNG library (one of at least 2 ways to extend PNG images to support the same sort of simple animation as supported in GIF) among others. Yet another factor that really bloated libraries was extending them to support 32bit and then 64bit systems, and to support UTF-8 and internationalization, solve Y2K issues, and so on. Libraries can lead to code bloat by hiding too much-- many application programmers will use a huge, slow, and complicated library function to do some simple little task, unaware that the library function they chose is overkill. In short, libraries have become layers upon layers of bandaids and upgrades. Projects intended for support of embedded hardware, such as uclibc and busybox, are various approaches to dealing with this bloat, but these are piecemeal. Eventually, it may be worth undertaking the huge, organized effort to catalog everything and rewrite all the useful library functionality in whatever better programming language we have yet to invent, finally get the Unix system to leave C behind.
(Score: 2) by Thexalon on Friday January 29 2016, @02:09PM
Explain this to me then: What's the difference, conceptually, between (A) a VM host running a unikernel capable of solving one particular kind of problem, and (B) an OS running on bare metal running a process capable of solving one particular kind of problem?
As in, they seem to be identical: In both cases, whatever is talking to the actual hardware is responsible for allocating and managing resources. And then there's something else that uses whatever is talking to the hardware that solves the users' problem.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by TheRaven on Sunday January 31 2016, @10:20AM
Explain this to me then: What's the difference, conceptually, between (A) a VM host running a unikernel capable of solving one particular kind of problem, and (B) an OS running on bare metal running a process capable of solving one particular kind of problem?
They are very similar. The main difference is the shape of the OS APIs. In the former scenario, the host provides things that look like CPUs, NICs and things that look like block devices, with no high-level abstractions (e.g. threads, sockets, and filesystems). If these are needed, then the unikernel will link in device libraries that provide them. In contrast, in the later situation the OS will be providing these even when they are not needed and they will add overhead to those code paths.
Additionally, the amount of process state owned by the OS is far greater in the latter case. Things like file descriptors, thread priorities and so on make it far harder to snapshot or migrate an OS process. Hypervisor interfaces tend to be as close to stateless as possible.
sudo mod me up
(Score: 2) by darkfeline on Friday January 29 2016, @08:27PM
So you're basically compiling an application and the OS together as one optimized, statically linked unit.
That seems pretty useful for specific use cases, but it's the kind of idea that attracts people who want to use it to do everything (e.g., write EVERYTHING in JavaScript, make EVERYTHING into unikernels).
Join the SDF Public Access UNIX System today!