4 ms·
As I've always understood it, it's not just performance but also security: there's a lot less code running with your code which cuts the surface area for bugs a
by radicalbyte 6y ago
As I've always understood it, it's not just performance but also security: there's a lot less code running with your code which cuts the surface area for bugs and thus security holes.
- cma 6y agoWouldn't a crash or other problem in your program potentially corrupt e.g. the kernel tcp stack?
- rwmj 6y agoAs the program and kernel run in a single address space, yes there is no separation from your application corrupting parts of the kernel. I'm not very convinced about the security story around unikernels, but for balance the other side of the argument is that there's much less code around in a unikernel - no shell, no command line tools at all, no compilers or interpreters, just the code required to run the program and talk to the hardware (real or virtual).
- heavenlyblue 6y agoWouldn’t directly linking system calls make every address space more unique and thus make it harder to write (generic) exploits for?
- rwmj 6y agoThe typical problem is that you end up distributing (eg) Apache 2.4.99 compiled for Unikernel on x86-64 via Red Hat Network to a million customers and they're all running the same binary. ASLR helps here ...
- cma 6y agoWith full privilege I think you could directly write to hardware dma locations and look them up in the mmu, etc.
- kbumsik 6y ago> there's a lot less code running with your code Tell me if I am wrong, but is it always true though? Unikernel libraries definitely are largely not as proven as Linux kernel. Then how is unikernel secure than Linux system call?