Ability to call into kernel's x.509 parsing functions

[alex]

I'm very excited by lkl for a project I"m working on, however I need access to the kernel's x509 functions, specifically x509_cert_parse (https://github.com/torvalds/linux/blob/master/crypto/asymmetric_keys/x509_cert_parser.c#L68).

However, I don't see this in strings lkl.o. I'd be great if this could be added! Not sure if that's just a matter of adjusting the .config or if more work is involved.

[thehajime]

hi @alex,

see the related discussion in #17.
currently lkl only exposes symbols for lkl system calls and the rest of symbols marked as private ones. so its not a matter of .config.

[alex]

My interest is primarily in fuzzing of various linux kernel APIs, which are not exposed as syscalls. Is it reasonable to want to use lkl for this, or is it outside your goals?

[thehajime]

I'm on the side where symbols in liblkl.so should be exposed (while @tavip not) :)
this is still under discussion.

I believe fuzz testing is definitely in the lkl's scope.
if you would like to try to call the function, you may need to expose it with a proper prefix to all exposed symbols in order to conflict with outside of lkl (something like libos-nuse/net-next-nuse@751adb6).

[pscollins]

For now, the thing to do might be to add the symbols you're interested in to LKL_ENTRY_POINTS in arch/lkl/Makefile and make sure the appropriate .config options are turned on. I couldn't get that particular symbol to show because it involves chasing down .config options to make sure that the x509 stuff is built, but for e.g. zlib_deflate, adding it to LKL_ENTRY_POINTS makes it show up in lkl.o:

➜  lkl git:(export-509) ✗ nm -g lib/lkl.o | grep -B 5 zlib 
0000000000001217 T lkl_start_kernel
0000000000015140 T lkl_syscall
00000000000145a0 T lkl_sys_halt
0000000000014bc0 T lkl_trigger_irq
0000000000374090 T schedule
000000000027e6e0 T zlib_deflate

Then you'd want to follow the example of how tools/lkl/Makefile/tests/boot.c is built to get that symbol available to your code. Pulling out arbitrary functions from the kernel, it's very likely that you'll eventually hit one that won't work from userspace without some kind of shim, but the certificate parser looks pretty tame to me.

It's tricky because on the one hand, it would be great to expose the whole kernel to userspace, but on the other hand, most code you expose that way is going to be broken, and it seems wrong to drop ~10M lines of undocumented (as far as using it as a library is concerned) code onto the user's lap.

A compromise might be to provide a nice, documented way to pick extra symbols to expose (e.g. say LKL_ENTRY_POINTS += $(EXTRA_SYMS) and pull from the environment) with a big warning that you're adding things at your own risk.