Imagine we wanted to allow building a kernel that is customized to a
specific app - in other words, it provides more-less only the functionality
needed by the aforementioned app and nothing more. Please note that one of
the previous conversations was about creating "microVM" version of the
kernel.elf which is also customized but to a specific type of hypervisor.
So how could we achieve this?
It turns out it is now that difficult as long as we rely on a
version script and the linker garbage collecting all unneeded code and
data. All we need to do is to manufacture a custom version script that
exports symbols only needed by the given app. For example, a native hello
world would have a version script like this:
{
global:
__cxa_finalize;
__gmon_start__;
_ITM_deregisterTMCloneTable;
_ITM_registerTMCloneTable;
__libc_start_main;
puts;
local:
*;
};
I have hand-crafted it but it can be quite easy to automate the generation
of it like this:
nm -uD apps/native-example/hello
After re-linking with this specific version script we arrive with
kernel.elf that is only 2.7M in size (2728432 bytes) and exposes 3 symbols
only:
nm -CD build/release/kernel.elf
00000000402233b0 T __cxa_finalize
00000000403211c0 T __libc_start_main
0000000040357480 T puts
The size difference is around 10% which is not that dramatic but one
advantage is that the kernel exposes only symbols needed by the app so it
is somewhat more secure.
I have also experimented with more non-trivial apps like redis and tomcat
(java) and even then the resulting kernel.elf was still around 2.7M
(2826976 bytes) and around 400 symbols exposed. For java that depends on
many shared libraries and I had to sum all the needed symbols sets and
intersect them with the ones from the generic kernel version script.
Please note that the above-sketched recipe to produce customized kernel
does not require re-compiling any kernel sources but only re-linking the
final artifact - kernel.elf - to provide only needs symbols and eliminate
any unneeded code and data. Which means it is pretty fast (unless you start
using lto about which I will write later).
Waldek
--
You received this message because you are subscribed to the Google Groups "OSv
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/osv-dev/da86ac70-a301-47e0-a870-1b4a1b3b4913n%40googlegroups.com.
