5 ms·
This is really well written, thanks for sharing. I didn't understand the point of using Unikraft though, if you can boot linux in much less than 150ms, with a
by deivid 8mo ago
This is really well written, thanks for sharing.
I didn't understand the point of using Unikraft though, if you can boot linux in much less than 150ms, with a far less exotic environment
- pjmlp 8mo agoSecurity, it isn't only memory footprint.
- iberator 8mo agoWhich architecture can boot it in 150ms ?!
- binsquare 8mo agoMicrovm's
- jumploops 8mo agoBoot is a misleading term, but you can resume snapshotted VMs in single digit ms (and without unikernels, though they certainly help)
- deivid 8mo agoYou can boot a vm without snapshots in < 10ms, just need a minimal kernel.
- hun3 8mo agoStripping away unused drivers (.config) and other "bloats" can get you surprisingly far.
- iberator 8mo agoBut 150ms? That's boot time for dos or minix maybe (tiny kernels). 1s sure.
- deivid 8mo agoYou can do <10ms. I was working to see if I could get it under 1ms, but my best was 3.5ms
- balou23 8mo agoFreeBSD did some work to boot in 25ms. Source: https://www.theregister.com/2023/08/29/freebsd_boots_in_25ms/ https://www.theregister.com/2023/08/29/freebsd_boots_in_25ms...
- gpderetta 8mo agofor example: https://firecracker-microvm.github.io/ https://firecracker-microvm.github.io/
- TacticalCoder 8mo agoAnd most importantly and TFA mentions it several times: stripping unused drivers (and even the ability to load drivers/modules) and bloat brings very real security benefits. I know you were responding about the boot times but that's just the icing on the cake.
- hun3 8mo agoMostly depends on how bloat correlates to attack surface, but you're right
- rwmj 8mo agoI think "in a VM" was elided. It's easy to tune qemu + Linux to boot up a VM in 150ms (or much less in fact). Real hardware is unfortunately limited by the time it takes to initialize firmware, some of which could be solvable with open source firmware and some (eg. RAM training) is not easily fixable.
- nderjung 8mo agoHey! Co-founder of Unikraft here. Unikraft aims to offer a Linux-compatible environment (so it feels familiar) with the ability to strip out unnecessary internal components in order to improve both boot-time/runtime performance and operational security. Why would you need a memory allocator and garbage collector if you serve static content? Why would you need a scheduler if your app is run-to-completion? Linux gives you the safety-net of generality and if you want to do anything remotely performant, you by-pass/hack it altogether. In the article, Unikraft cold-boots in 150ms in an emulated environment (TCG). If it was running natively with virtualization hardware extensions, it can be even shorter, and without the need for snapshots which means you don't need to store this separately either.
- deivid 8mo agoUnikraft is cool, I still have it in my 'todo' list to play around with sometime. Linking the app with the 'kernel' seems pretty nice, would be cool to see what that looks like for a virtio-only environment. Just wanted to point out that the 150ms is not snapshot based, you can get <10ms for small vms (128MB ram, 2GB ram moves you to ~15ms range), for 'cold' boots.
- victorbjorklund 8mo agoBecause it will be slightly faster and you will use less resources? For a lot of use cases that probably does not matter but for some it does.