[0/5] libkmod: Use kernel decompression support

Message

Lucas De Marchi June 1, 2023, 10:39 p.m. UTC

When kernel is built with CONFIG_MODULE_DECOMPRESS=y, it can handle 1
algorithm for module decompression with finit_module(). When that
algorithm matches the one used in the module we are trying to load,
prefer using the in-kernel decompression.  This way the kernel can also
apply any additional security measures based on where the module is
coming from.

In future, if the kernel supports more algorithms at a time, libkmod
could even be compiled without them and just let the kernel handle it.
Since it's likely a distro kernel supports all of them, that would
seem a good thing to do (on the other hand, tools like modinfo and
depmod wouldn't be able read the module information).

For zstd, this needs the following fix on the kernel side:
https://lore.kernel.org/linux-modules/[e-mail]/

Lucas De Marchi (5):
  libkmod: Do not inititialize file->memory on open
  libkmod: Extract finit_module vs init_module paths
  libkmod: Keep track of compression type
  libkmod: Keep track of in-kernel compression support
  libkmod: Use kernel decompression when available

 libkmod/libkmod-elf.c      |   5 ++
 libkmod/libkmod-file.c     |  46 +++++++++-----
 libkmod/libkmod-internal.h |  13 +++-
 libkmod/libkmod-module.c   | 127 ++++++++++++++++++++++++-------------
 libkmod/libkmod.c          |  42 ++++++++++++
 5 files changed, 170 insertions(+), 63 deletions(-)

Comments

Lucas De Marchi July 24, 2023, 1:28 p.m. UTC | #1

On Thu, Jun 01, 2023 at 03:39:56PM -0700, Lucas De Marchi wrote:
>When kernel is built with CONFIG_MODULE_DECOMPRESS=y, it can handle 1
>algorithm for module decompression with finit_module(). When that
>algorithm matches the one used in the module we are trying to load,
>prefer using the in-kernel decompression.  This way the kernel can also
>apply any additional security measures based on where the module is
>coming from.
>
>In future, if the kernel supports more algorithms at a time, libkmod
>could even be compiled without them and just let the kernel handle it.
>Since it's likely a distro kernel supports all of them, that would
>seem a good thing to do (on the other hand, tools like modinfo and
>depmod wouldn't be able read the module information).
>
>For zstd, this needs the following fix on the kernel side:
>https://lore.kernel.org/linux-modules/[e-mail]/
>
>Lucas De Marchi (5):
>  libkmod: Do not inititialize file->memory on open
>  libkmod: Extract finit_module vs init_module paths
>  libkmod: Keep track of compression type
>  libkmod: Keep track of in-kernel compression support
>  libkmod: Use kernel decompression when available

thank you all for the reviews. I just pushed all the patches here.

Lucas De Marchi

>
> libkmod/libkmod-elf.c      |   5 ++
> libkmod/libkmod-file.c     |  46 +++++++++-----
> libkmod/libkmod-internal.h |  13 +++-
> libkmod/libkmod-module.c   | 127 ++++++++++++++++++++++++-------------
> libkmod/libkmod.c          |  42 ++++++++++++
> 5 files changed, 170 insertions(+), 63 deletions(-)
>
>-- 
>2.40.1
>