Hypothetically, if there were a buffer overflow in a unikernel process, wouldn't it potentially give the exploit full-system access, whereas a normal operating system would detect the out-of-bounds memory access and kill the process? I'm sorry if this is an ignorant question.
First, standard page fault mechanisms would still be in place, that's a processor/architecture feature, so out of bounds memory access would be detected just as in a normal operating system. Of course, a normal operating system does not detect many/most buffer overflows.
In general, you could have a unikernel where it's impossible to get executable buffer overflow because there are no memory pages that are both writable and executable - as the article describes, that'd need some help from the hypervisor for the initialization.
Return oriented programming exploits could work anyway, though.
I could be wrong, but I think this is what Memory Management Units are for, on processor chips. It's one major differentiator between application processors and more embedded ones like Cortex-M or ATMega MCUs, which typically can't run complex modern operating systems. A lot of those chips have a simpler Memory Protection Unit that does basic enforcement of permissions like read+execute, read+write, etc, but they lack the ability to partition memory virtually between a large number of potential 'owners.'
I think - I'm still learning about this embedded stuff.
The point is that once you're doing that, and implementing communication between all your separate owners (which map pretty precisely to a reasonable definition of "processes")... you've just implemented another operating system, not a unikernel.
I'm not super familiar with this, but it seems like the question is what is "full-system" in this case if each application is sandboxed with its own embedded kernel? I mean there's no shell, ostensibly all other applications and system functions are bundled similarly, right?
It'd make exploits more difficult, but you'd still be able to upload your own code to do whatever you want.
The trouble is that instead of uploading "/bin/sh" you'd have to upload the whole shell which you'd want to run; instead of making a syscall for something that a normal kernel would do but this one doesn't, you'd have to compile and upload appropriate code (including device drivers) to get that done.
Not necessarily. The kernel can run the code in non ring 0, ie in userspace. I can't speak to what is typical, but i imagine you'd get most of your gains by stripping most vulnerable code out of the system outright.
> if there were a buffer overflow in a unikernel process, wouldn't it potentially give the exploit full-system access
Yes
> whereas a normal operating system would detect the out-of-bounds memory access and kill the process?
No. A buffer overflow in a normal operating system usually results in the the attacker gaining control over the process that the buffer overflow occurred in. This is not as bad as an attacker gaining full system access, but is generally plenty for an attacker to accomplish their goals.
Best i can tell, unikernels are a reaction to the shift from VMs to containers in cloud services. This by pairing down the content of a VM to the bare minimum.
Meaning that if you have a buffer overflow or similar, all you could access was what was in the VM (unless you also happen to pack a VM escape).
That said, i can't help think "DOS in a can" whenever i read about unikernels.
If it wasn't for the negative connotations people have with DOS I'd say it a lot more. Implementing a unikernel chain loader and a simple shell would be quite simple. That would be quite DOS-like.
IncludeOS actually came out of a research need to stress-test hypervisors and run 10000 VMs on a single host. Since it is a clean slate system it has some different characteristics and those can be exploited in certain use cases and so people have kept on working on it.
