Charlie Jacobsen authored Feb 08, 2016 and Vikram Narayanan committed Oct 26, 2016

Adds two new functions to liblcd interface - lcd_module_load and
lcd_module_unload - for loading a kernel module from disk and into
the caller's address space. (Interface designed so that at some
point in the future, liblcd can implement these for isolated
code.)

The kliblcd implementation uses the host module loader to bring
in the kernel module from disk (as before), but now we duplicate
the entire module (rather than just the struct module pages).

Motivation: There are numerous bits embedded in the kernel module's
image (struct module, symbol tables, string tables, and possibly
more) that the host uses during kallsyms lookup, module linked-list
traversal, and so on, and it wouldn't be safe for the module loader
to share that with the LCD. (The module loader wasn't designed
to share bits with a potentially malicious or buggy peer.) It's
simpler to just duplicate the entire module image (init and core).

The other advantage is once we've made the duplicate, we can
unload the copy in the host module loader (all we needed were the
program bits).

IMPORTANT: This has some significant implications:

  1 - It means means we no longer have to look up the host's copy
      of the struct module in the receiving side of glue code for
      e.g. register_filesystem. (The struct module will be treated
      just like any other struct.)

      I think overall this will be a good thing, and we won't run into
      serious problems in the near future. Functions like
      register_filesystem bump the reference count on the struct
      module. When the user tried to unload the kernel module, the host
      checks that the reference count goest to zero. Now, we need to
      ensure instead that the LCD that contains the module won't go
      away (e.g. before all file systems it is responsible for have
      been unmounted). We'll have to cross that bridge when we get there.

  2 - Some of the host utility functions for e.g. symbol lookup will
      not work as is. But I see some workarounds.

The other big change is now we're using more coarse-grained
capability management for the module pages (only two capabilities -
one for init vmalloc mem, one for core vmalloc mem, rather than
a capability for each page). I need to now implement
lcd_vmalloc/lcd_vfree in order for this code to be fully ready.

Note: I considered linking the kernel module at a lower address
so that we can use a direct map in the LCD's virtual address
space. And this may be possible now that we're unloading the
module right after we load it. But it's a bit risky since the
host uses some of the section addresses for symbol and exception
table lookup, and maybe others (if I linked it for a lower
address, the host would crash or use random memory). The benefits
didn't seem to outweigh the risks.