• Kees Cook's avatar
    module: add syscall to load module from fd · 34e1169d
    Kees Cook authored
    As part of the effort to create a stronger boundary between root and
    kernel, Chrome OS wants to be able to enforce that kernel modules are
    being loaded only from our read-only crypto-hash verified (dm_verity)
    root filesystem. Since the init_module syscall hands the kernel a module
    as a memory blob, no reasoning about the origin of the blob can be made.
    
    Earlier proposals for appending signatures to kernel modules would not be
    useful in Chrome OS, since it would involve adding an additional set of
    keys to our kernel and builds for no good reason: we already trust the
    contents of our root filesystem. We don't need to verify those kernel
    modules a second time. Having to do signature checking on module loading
    would slow us down and be redundant. All we need to know is where a
    module is coming from so we can say yes/no to loading it.
    
    If a file descriptor is used as the source of a kernel module, many more
    things can be reasoned about. In Chrome OS's case, we could enforce that
    the module lives on the filesystem we expect it to live on.  In the case
    of IMA (or other LSMs), it would be possible, for example, to examine
    extended attributes that may contain signatures over the contents of
    the module.
    
    This introduces a new syscall (on x86), similar to init_module, that has
    only two arguments. The first argument is used as a file descriptor to
    the module and the second argument is a pointer to the NULL terminated
    string of module arguments.
    Signed-off-by: default avatarKees Cook <keescook@chromium.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (merge fixes)
    34e1169d
sys_ni.c 5.87 KB