Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IncludeOS: C++ unikernel now free and open source

github.com

Post reply on HN
Print view View original

21–30 of 43 posts

Re: IncludeOS: C++ unikernel now free and open source

#21

Post by wtallis »

creshal wrote: post #7
meesterdude wrote: post #2

> A minimal bootable image, including bootloader, operating system components and a complete C++ standard library is currently 693K when optimized for size. WOW. That's just nuts! I mean I know linux can be slim, but thats less than a meg! Really very exciting stuff. I don't know if I should play JC3 or tinker with this.

I'm pretty sure you can find MIPS Linux images with Busybox et. all. that weigh less than that. A lot of routers run Linux on 2M eproms including user space.

You won't find anything remotely recent squeezing into a mere 2MB. You can't really get Linux that slim anymore without cutting out major things like the network stack. 4MB is still (just barely) enough ROM for a real router, if you're judicious about what features to include, and don't mind the lack of a browser-based configuration interface.

Re: IncludeOS: C++ unikernel now free and open source

#22

Post by bonzini »

cbsmith wrote: post #20
nathankunicki wrote: post #18

Earlier quoted context omitted.

Not strictly, no. While currently they only support the "hardware" in KVM/QEMU/VirtualBox, there's nothing stopping anyone implementing drivers for whatever hardware they want to run on, even bare metal. This probably means integrating whatever Ethernet adapter you have, and some way of sending/receiving stdio, probably over serial or something. Sideline: I'm particularly intrigued by the idea of implementing drivers…

> I'm particularly intrigued by the idea of implementing drivers for AWS EC2, so you can run this as your AMI. Yup. Kind of like a skimpy version of OSv.

Yeah, how does this compare to OSv?

Re: IncludeOS: C++ unikernel now free and open source

#23

Post by pjc50 »

cbsmith wrote: post #16
david-given wrote: post #10

Earlier quoted context omitted.

I have a port of Alan Cox's Fuzix for the MSP430 where the entire bootable ROM image is 27kB. (That's actually quite big for a tiny-computer OS, although it's the smallest Unix I know of.)

I seem to recall the QNX kernel is pretty slim as well.

I used to have a 1.44Mb floppy that booted QNX to a desktop environment. Of course, that's not so unusual historically: both Amiga and GEM had single-floppy desktop enviroments (or did the Amiga require two to get to Workbench?)

Re: IncludeOS: C++ unikernel now free and open source

#24

Post by pjc50 »

cbsmith wrote: post #15
yaantc wrote: post #9

Earlier quoted context omitted.

When using a unikernel design there is no isolation between a single node software components like an OS can provide. All the code share the same memory space. Isolation can be useful. For example the Postfix email server (running on a Unix, not unikernel) is decomposed into several processes with different privileges. That allows running the most sensitive parts with limited access rights, to protect against attacks…

> That allows running the most sensitive parts with limited access rights, to protect against attacks, while still running those parts on the same server for efficiency. This process isolation is typically not provided with unikernels. Unikernels also don't have notions of access rights. To make that model work, more than memory safety, you need declarative ways of asserting constraints, which... C++ arguably can pul…

Possible, but not necessarily easy; what tools do you use to sweep C++ code for 'unsafe' constructs?

Re: IncludeOS: C++ unikernel now free and open source

#25

Post by uxcn »

nathankunicki wrote: post #18
pantalaimon wrote: post #11

Earlier quoted context omitted.

It still needs a 'real' OS (e.g. Linux) running as the Hypervisor. The entire concept appears to me like a fancy ELF, cause we couldn't solve the problem of packaging software in a portable way before, apparently.

Not strictly, no. While currently they only support the "hardware" in KVM/QEMU/VirtualBox, there's nothing stopping anyone implementing drivers for whatever hardware they want to run on, even bare metal. This probably means integrating whatever Ethernet adapter you have, and some way of sending/receiving stdio, probably over serial or something. Sideline: I'm particularly intrigued by the idea of implementing drivers…

> Not strictly, no. While currently they only support the "hardware" in KVM/QEMU/VirtualBox, there's nothing stopping anyone implementing drivers for whatever hardware they want to run on, even bare metal.

Exokernels (https://en.wikipedia.org/wiki/Exokernel) essentially implement this. Hardware has been adding more support for virtualization though, so I imagine unikernels are better able to take advantage of things like virtualized page tables, virtualized io-mmu, etc...

I'd be curious to see benchmarks for something generally IO bound like PostgreSQL or HyperTable. IO scheduling isn't trivial, so it might give a good idea of what some of the trade-offs might be.

Re: IncludeOS: C++ unikernel now free and open source

#26

Post by nickpsecurity »

cbsmith wrote: post #19
pantalaimon wrote: post #11

Earlier quoted context omitted.

It still needs a 'real' OS (e.g. Linux) running as the Hypervisor. The entire concept appears to me like a fancy ELF, cause we couldn't solve the problem of packaging software in a portable way before, apparently.

> It still needs a 'real' OS (e.g. Linux) running as the Hypervisor. It runs against hardware virtualization... I'm not sure I understand why it needs a "real" OS underneath. At least in theory it should be able to run on bare metal as long as you include logic for whatever device drivers you might need.

Microkernel and RTOS work shows anything it needs can be about as tiny as itself. Tinier, actually, if it's a networked service with a single app running. It already has networking, needs a driver, a few special-purpose components... not much left to add.

Re: IncludeOS: C++ unikernel now free and open source

#27

Post by pcwalton »

cbsmith wrote: post #15
yaantc wrote: post #9

Earlier quoted context omitted.

When using a unikernel design there is no isolation between a single node software components like an OS can provide. All the code share the same memory space. Isolation can be useful. For example the Postfix email server (running on a Unix, not unikernel) is decomposed into several processes with different privileges. That allows running the most sensitive parts with limited access rights, to protect against attacks…

> That allows running the most sensitive parts with limited access rights, to protect against attacks, while still running those parts on the same server for efficiency. This process isolation is typically not provided with unikernels. Unikernels also don't have notions of access rights. To make that model work, more than memory safety, you need declarative ways of asserting constraints, which... C++ arguably can pul…

> C++ has lots of support for language level isolation. Yes, due to C compatibility, if you diddle with memory you can find ways to violate those contracts,

No, it's not. The memory unsafety in C++ is fundamental to the language (think iterator invalidation). It has nothing to do with C compatibility and comes up all the time in well-written C++ code in practice.

Re: IncludeOS: C++ unikernel now free and open source

#28

Post by nickpsecurity »

DiabloD3 wrote: post #17

So anyone know how small the L4 kernel is compared to this?

5-10 times smaller for regular ones with it closer to 50 for separation kernels. That's not a fair comparison, though, as you need extra components to support the unikernel or just components on the kernel. A more fair comparison might be L4Re, a stripped GenodeOS, OKL4 w/ necessary software, or NOVA with necessary software.

L4Re was the first attempt I believe at an environment for apps on L4:

https://os.inf.tu-dresden.de/L4Re/overview.html

Re: IncludeOS: C++ unikernel now free and open source

#29

Post by nickpsecurity »

pjc50 wrote: post #24
cbsmith wrote: post #15

Earlier quoted context omitted.

> That allows running the most sensitive parts with limited access rights, to protect against attacks, while still running those parts on the same server for efficiency. This process isolation is typically not provided with unikernels. Unikernels also don't have notions of access rights. To make that model work, more than memory safety, you need declarative ways of asserting constraints, which... C++ arguably can pul…

Possible, but not necessarily easy; what tools do you use to sweep C++ code for 'unsafe' constructs?

I'm interested in the answer to that, too. A member of the Chrome team asked what static analysis or advanced verification tools I thought they could use in a significant C++ project. Digging around, I think I just found one, limited one plus two ways of doing Design-by-Contract (asserts & OOP). That was it. Not inspiring lol.

Now, there has been work on type-safe or memory-safe version of C++. They're non-standard. They also get smashed when a memory error occurs and that will happen. So, suggesting to rely on language-based isolation in C++ is a more a joke than something worth trying.

Good example of work on C++ safety:

https://www.cis.upenn.edu/~eir/papers/2013/ironclad/paper.pd...

Re: IncludeOS: C++ unikernel now free and open source

#30

Post by nickpsecurity »

meesterdude wrote: post #2

> A minimal bootable image, including bootloader, operating system components and a complete C++ standard library is currently 693K when optimized for size. WOW. That's just nuts! I mean I know linux can be slim, but thats less than a meg! Really very exciting stuff. I don't know if I should play JC3 or tinker with this.

Should look at systems of the past for inspiration on that. Remember that old systems couldn't waste MB on stuff. So, they got clever. Hansen's Solo had 4KB trusted kernel with whole OS being 21Kloc of readable Pascal with total image size of 110KB. That includes kernel, filesystem, I/O, editor, and two compilers. Result was type-safe, mostly memory-safe, and concurrency-safe (deadlock & race condition free specifically). People could copy and update old approaches like that for OS side of things then they don't even need a unikernel. ;)

Now, wanting strong separation mechanisms and so on would complicate things. The old security kernels, like STOP OS and GEMSOS, used MMU's, segments, MAC policies, covert channel suppression... you name it. STOP was still only 21,000 Kloc in total:

http://www.cse.psu.edu/~trj1/cse544-s10/slides/cse544-lec9-1...

So, monolithic or micro-kernel route, you can get things way smaller at the foundation than what we use today. Add basic TCP/IP stack, Ethernet driver, and runtime it should still be way smaller than 693K unless that's tons of error or security handling code to increase robustness.

Post reply on HN