Linux Modules
 help / color / mirror / Atom feed
* [PATCH 0/5] libkmod: Use kernel decompression support
@ 2023-06-01 22:39 Lucas De Marchi
  2023-06-01 22:39 ` [PATCH 1/5] libkmod: Do not inititialize file->memory on open Lucas De Marchi
                   ` (5 more replies)
  0 siblings, 6 replies; 18+ messages in thread
From: Lucas De Marchi @ 2023-06-01 22:39 UTC (permalink / raw)
  To: linux-modules; +Cc: Luis Chamberlain, Lucas De Marchi

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/ZHkQNQK5zrzo4Cq2@bombadil.infradead.org/

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(-)

-- 
2.40.1


^ permalink raw reply	[flat|nested] 18+ messages in thread
* Re: [PATCH 5/5] libkmod: Use kernel decompression when available
@ 2023-06-15  9:36 Emil Velikov
  2023-06-15 10:09 ` Emil Velikov
  2023-06-16  5:12 ` Lucas De Marchi
  0 siblings, 2 replies; 18+ messages in thread
From: Emil Velikov @ 2023-06-15  9:36 UTC (permalink / raw)
  To: Lucas De Marchi; +Cc: linux-modules

Greetings Lucas, list,

I've pulled the email off lore.kernel.org manually (haven't played
with lei yet), so chances are the following will be "slightly"
malformed.

Above all - hell yeah, thank you for wiring this neat functionality.

Out of curiosity: have you done any measurements - CPU cycles, memory
or other - how well the kernel decompression performs vs the userspace
one?

That said, I may have spotted a small bug, namely:

> --- a/libkmod/libkmod-module.c
> +++ b/libkmod/libkmod-module.c
> @@ -864,15 +864,24 @@ extern long init_module(const void *mem, unsigned long len, const char *args);
>  static int do_finit_module(struct kmod_module *mod, unsigned int flags,
>     const char *args)
>  {
> + enum kmod_file_compression_type compression, kernel_compression;
>  unsigned int kernel_flags = 0;
>  int err;
>
>  /*
> - * Re-use ENOSYS, returned when there is no such syscall, so the
> - * fallback to init_module applies
> + * When module is not compressed or its compression type matches the
> + * one in use by the kernel, there is no need to read the file
> + * in userspace. Otherwise, re-use ENOSYS to trigger the same fallback
> + * as when finit_module() is not supported.
>  */
> - if (!kmod_file_get_direct(mod->file))
> - return -ENOSYS;
> + compression = kmod_file_get_compression(mod->file);
> + kernel_compression = kmod_get_kernel_compression(mod->ctx);
> + if (!(compression == KMOD_FILE_COMPRESSION_NONE ||
> +       compression == kernel_compression))
> + return ENOSYS;
> +

Old code returns negative -ENOSYS (negative), the new one a positive
ENOSYS. Where the fallback, mentioned in the comment just above,
triggers on the former negative ENOSYS.

Mind you I'm still sipping coffee, so chances are I'm missing something here.

Thanks again and HTH o/
Emil

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2023-07-24 13:28 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-06-01 22:39 [PATCH 0/5] libkmod: Use kernel decompression support Lucas De Marchi
2023-06-01 22:39 ` [PATCH 1/5] libkmod: Do not inititialize file->memory on open Lucas De Marchi
2023-06-06 18:24   ` Luis Chamberlain
2023-06-01 22:39 ` [PATCH 2/5] libkmod: Extract finit_module vs init_module paths Lucas De Marchi
2023-06-06 18:27   ` Luis Chamberlain
2023-06-01 22:39 ` [PATCH 3/5] libkmod: Keep track of compression type Lucas De Marchi
2023-06-06 18:28   ` Luis Chamberlain
2023-06-01 22:40 ` [PATCH 4/5] libkmod: Keep track of in-kernel compression support Lucas De Marchi
2023-06-06 18:29   ` Luis Chamberlain
2023-06-06 18:30   ` Luis Chamberlain
2023-06-01 22:40 ` [PATCH 5/5] libkmod: Use kernel decompression when available Lucas De Marchi
2023-06-06 18:38   ` Luis Chamberlain
2023-06-06 19:01     ` Lucas De Marchi
2023-07-24 13:28 ` [PATCH 0/5] libkmod: Use kernel decompression support Lucas De Marchi
  -- strict thread matches above, loose matches on Subject: below --
2023-06-15  9:36 [PATCH 5/5] libkmod: Use kernel decompression when available Emil Velikov
2023-06-15 10:09 ` Emil Velikov
2023-06-27 14:05   ` Lucas De Marchi
2023-06-16  5:12 ` Lucas De Marchi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox