4 ms·

How would includeos work with the Amazon specific network hardware or does something like firecracker abstract the network stack fully? Where do the network dri

How would includeos work with the Amazon specific network hardware or does something like firecracker abstract the network stack fully? Where do the network drivers live?

ncmncm 5y ago
I don't really know much specific about Amazon. But any network drivers you need are linked, or compiled, right into your program, instead of in a kernel you run on top of. If Amazon is providing a virtualized NIC, you compile in drivers for that under the IP stack you have also compiled in. Amazon's hypervisor might proxy access to actual or synthetic network devices, or might map a real NIC into your VM, or they might even boot your program on a real machine with real NIC, for all the world as if it is booting a proper kernel. It really is as if your app is your kernel, which just doesn't bother with any sort of user programs, because your code is all right there. Instead of doing system calls, it just does regular function calls to what would have been kernel services. Because it is all just one program, you can inline a lot of stuff that would normally have a system call or module indirection interposed. This would be a good place for LTO, to inline everything that could benefit by it.
- smackeyacky 5y ago
  So its like a lambda that doesnt have the run time limits Amazon impose? I kinda like the idea (I like the AWS lambdas for short running tasks triggered by events) but if you want what is effectively a long running lambda, then a container is really the next logical step. I guess there is room between a lambda and a container but not much room.
  - curryst 5y ago
    Not really, it effectively adds a kernel to your app so your app is the OS. Like if you were booting from Grub, you would point Grub at your app binary directly. You don't boot into Linux and start your app, your app is the OS. Iirc the main advantages are eliminating a lot of context switching (your app is the kernel, so theres no context switching for kernel calls) and reducing unneeded features (i.e. if your app doesn't need networking, then it won't put any network drivers in your app-OS). Its mostly a performance optimization afaik. There's some supposed security features because it drops parts of the OS you don't need, which reduces the attack surface. I don't know if there are any additional risks from it though; making the app run in ring 0 makes me uneasy. I think that might just be because passing from userland to kernel land is a significant exploit in normal OS'.

How would includeos work with the Amazon specific network hardware or does something like firecracker abstract the network stack fully? Where do the network drivers live?

ncmncm 5y ago

I don't really know much specific about Amazon. But any network drivers you need are linked, or compiled, right into your program, instead of in a kernel you run on top of. If Amazon is providing a virtualized NIC, you compile in drivers for that under the IP stack you have also compiled in. Amazon's hypervisor might proxy access to actual or synthetic network devices, or might map a real NIC into your VM, or they might even boot your program on a real machine with real NIC, for all the world as if it is booting a proper kernel. It really is as if your app is your kernel, which just doesn't bother with any sort of user programs, because your code is all right there. Instead of doing system calls, it just does regular function calls to what would have been kernel services. Because it is all just one program, you can inline a lot of stuff that would normally have a system call or module indirection interposed. This would be a good place for LTO, to inline everything that could benefit by it.

smackeyacky 5y ago
So its like a lambda that doesnt have the run time limits Amazon impose? I kinda like the idea (I like the AWS lambdas for short running tasks triggered by events) but if you want what is effectively a long running lambda, then a container is really the next logical step. I guess there is room between a lambda and a container but not much room.
- curryst 5y ago
  Not really, it effectively adds a kernel to your app so your app is the OS. Like if you were booting from Grub, you would point Grub at your app binary directly. You don't boot into Linux and start your app, your app is the OS. Iirc the main advantages are eliminating a lot of context switching (your app is the kernel, so theres no context switching for kernel calls) and reducing unneeded features (i.e. if your app doesn't need networking, then it won't put any network drivers in your app-OS). Its mostly a performance optimization afaik. There's some supposed security features because it drops parts of the OS you don't need, which reduces the attack surface. I don't know if there are any additional risks from it though; making the app run in ring 0 makes me uneasy. I think that might just be because passing from userland to kernel land is a significant exploit in normal OS'.