Hacker News Reader

Comment by br1n0 | Hacker News Reader

In other words templeos is a unikernel with a jit compiler. The name is odd, the author is strange, do you judge a movie by private life of the authors? The illness of van gogh, Gödel didn't affect their creations. missing graphical interface is a defect. An unikernal is a strange beast, sound crazy, but got some advantages: is simpler, could be understood completely by a human (and not only by a genius), there are no penality for system calls, and there is no cpu time wasted on context switch. Because the machine are getting cheaper is common to have only one user, so all these security became useless, so on the long run the unikernels will be mainstream. Kudos to him. a relevant discussion about unikernel here: https://news.ycombinator.com/item?id=10362897

View on HN

The advantage of multiple "users" isn't just blocking one person's access to another person's stuff. It's also a valuable tool for sandboxing system processes which need to run parallel on the same host system.

I'm addition to that, a monolithic unikernel (as unikernels usually are) would have the issue of a higher tendency for kernel panics.

So i really can't see unikernels becoming mainstream. If anything the reverse trend is true with more complex kernel designs like micro kernels becoming more favourable as computing hardware gets cheaper.

The real growth area for unikernels is virtualized appliances, eg running a single purpose service as a Xen unikernel. But even that is awfully niche and often better served (particularly in terms of developer and sysadmin productivity) with containers these days.

In that case, you need process isolation and permissions not user privileges. Prior models for mandatory, access control and capability-based security can already do what you're describing. KeyKOS did it in production on mainframes decades ago with extra benefit of persistence for app data. System/38 did one of those models, too, at CPU level. Later became AS/400 and IBM i. AS/400's run and run and run.

So, if you want POLA and damage containment, one option is imitating old designs that pulled that off. Patents expired, too. ;)

Oh I'm fully aware there are a thousand different ways to accomplish similar results. Further to your point, you can also support multiple physical users without actually running a multi-user system as well (eg Windows 95).

However you have to bare in mind that this tangent did start off as an exercise in generalisations so I was following on from that by pointing out that many current multi-user systems also use user accounts as a tool for reducing the exposure a process has. While you'd obviously agree that it's a long way from being the most secure method of hardening a OS, it is still a pretty typical way for many desktop systems to operate.

I think unikernels make sense in conjunction with languages like Rust. If your compiler is making sure it won't generate code that could cause a segfault, the run-time checks to do the same are unnecessary overhead.

(There are, of course, some details that would need to be worked out like how to handle unsafe code blocks, how to run programs written in unsafe languages, and how to enforce a policy of only executing code compiled with a trusted compiler, but none of these seem like fundamentally insurmountable obstacles and the benefits of being able to make a system call without any more overhead than a function call are pretty big for certain applications.)

I think you misunderstand the benefits of rust if you believe that writing the whole OS in rust makes any other security pointless.

I'm assuming that applications are written in Rust as well and that the OS is configured to either refuse to run binaries compiled with an unknown compiler or it runs them inside a CPU emulator.

And no, I don't think this solves all of the potential security problems that could exist. What it does accomplish (if you're willing to trust a compiler in the same way that we're expected to trust the MMU in our computers, which might not be warranted at this stage of the development of Rust) is that it solves the problem of one program reaching into another program's address space when it isn't supposed to.

Strictly speaking, it would be more secure to have both compiler-enforced protections and an MMU, so that a compiler bug won't compromise the whole system. It is, however, at least theoretically possible to have secure process isolation without relying on an MMU. That's a big deal, because context switches are expensive and if there's a way to get the same safety without the overhead, someone is likely to build a system that takes advantage of that.

I don't understand the definition of "unikernel" here. There's nothing preventing a microkernel architecture from being the basis of a unikernel.

Unikernel isn't the opposite of microkernel.

I didn't actually say a unikernel couldn't be a micro kernel though; just that there was a tendency for them to be monolithic.

Unless I've overlooked a bunch of kernels - and I'm happy to be proven wrong - usually you'll find unikernels to be monolithic because those two approaches address the similar objectives in kernel design (namely simpler layout and improved performance).

However correlation or not, you're probably right that my point regarding monolithic kernels wasn't entirely relevant to the rest of my post and thus just risks confusing things.

The ones I've seen so far are both monolithic and hosted on drivers/kernel of something monolithic. That's probably the rule for now.

I'd argue that Van Gogh isn't such a great example in this context...

Reply on news.ycombinator.com