Waldek, can you please describe what's your motivation in shrinking the size of the kernel? Compared for example to modern RAM and also to the JVM that many times will be there, the current size is already 'small enough', isn't it?
On Wed, Jun 10, 2020 at 9:55 PM Waldek Kozaczuk <[email protected]> wrote: > 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 > <https://groups.google.com/d/msgid/osv-dev/da86ac70-a301-47e0-a870-1b4a1b3b4913n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAKUaUn4c%2Bg2FVjbM3BA1OJprC_1_UWUrEChGaMEQj8RrAX_BFQ%40mail.gmail.com.
