linux-kernel - Re: [PATCH 1/2] module: Split modules_install compression and in-kernel decompression

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK7LNARMR1Pn3Rj6fC-u3qQC4jQGrasD1mqxg-8qPNPdTy61gw@mail.gmail.com>
Date: Sun, 28 Jul 2024 18:03:22 +0900
From: Masahiro Yamada <masahiroy@...nel.org>
To: Petr Pavlu <petr.pavlu@...e.com>
Cc: Luis Chamberlain <mcgrof@...nel.org>, Nathan Chancellor <nathan@...nel.org>, 
	Nicolas Schier <nicolas@...sle.eu>, linux-modules@...r.kernel.org, 
	linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] module: Split modules_install compression and
 in-kernel decompression

On Thu, Jul 25, 2024 at 9:59 PM Petr Pavlu <petr.pavlu@...e.com> wrote:
>
> On 7/22/24 12:23, Masahiro Yamada wrote:
> > On Mon, Jul 22, 2024 at 6:07 PM Petr Pavlu <petr.pavlu@...e.com> wrote:
> >>
> >> The kernel configuration allows specifying a module compression mode. If
> >> one is selected then each module gets compressed during
> >> 'make modules_install' and additionally one can also enable support for
> >> a respective direct in-kernel decompression support. This means that the
> >> decompression support cannot be enabled without the automatic compression.
> >>
> >> Some distributions, such as the (open)SUSE family, use a signer service for
> >> modules. A build runs on a worker machine but signing is done by a separate
> >> locked-down server that is in possession of the signing key. The build
> >> invokes 'make modules_install' to create a modules tree, collects
> >> information about the modules, asks the signer service for their signature,
> >> appends each signature to the respective module and compresses all modules.
> >>
> >> When using this arrangment, the 'make modules_install' step produces
> >> unsigned+uncompressed modules and the distribution's own build recipe takes
> >> care of signing and compression later.
> >>
> >> The signing support can be currently enabled without automatically signing
> >> modules during 'make modules_install'. However, the in-kernel decompression
> >> support can be selected only after first enabling automatic compression
> >> during this step.
> >>
> >> To allow only enabling the in-kernel decompression support without the
> >> automatic compression during 'make modules_install', separate the
> >> compression options similarly to the signing options, as follows:
> >>
> >>> Enable loadable module support
> >> [*] Module compression
> >>       Module compression type (GZIP)  --->
> >> [*]   Automatically compress all modules
> >> [ ]   Support in-kernel module decompression
> >>
> >> * "Module compression" (MODULE_COMPRESS) is a new main switch for the
> >>   compression/decompression support. It replaces MODULE_COMPRESS_NONE.
> >> * "Module compression type" (MODULE_COMPRESS_<type>) chooses the
> >>   compression type, one of GZ, XZ, ZSTD.
> >> * "Automatically compress all modules" (MODULE_COMPRESS_ALL) is a new
> >>   option to enable module compression during 'make modules_install'. It
> >>   defaults to Y.
> >> * "Support in-kernel module decompression" (MODULE_DECOMPRESS) enables
> >>   in-kernel decompression.
> >>
> >> Signed-off-by: Petr Pavlu <petr.pavlu@...e.com>
> >> ---
> >
> >
> >
> > My preference is to add
> >  CONFIG_MODULE_DECOMPRESS_GZIP
> >  CONFIG_MODULE_DECOMPRESS_XZ
> >  CONFIG_MODULE_DECOMPRESS_ZSTD
> > instead of
> >  CONFIG_MODULE_COMPRESS_ALL.
> >
> >
> >
> >
> > For example,
> >
> >
> > if MODULE_DECOMPRESS
> >
> > config MODULE_DECOMPRESS_GZIP
> >        bool "Support in-kernel GZIP decompression for module"
> >        default MODULE_COMPRESS_GZIP
> >
> > config MODULE_DECOMPRESS_XZ
> >        bool "Support in-kernel XZ decompression for module"
> >        default MODULE_COMPRESS_XZ
> >
> > config MODULE_DECOMPRESS_ZSTD
> >        bool "Support in-kernel ZSTD decompression for module"
> >        default MODULE_COMPRESS_ZSTD
> >
> > endif
> >
> >
> >
> >
> >
> > OR, maybe
> >
> >
> >
> > config MODULE_DECOMPRESS_GZIP
> >        bool "Support in-kernel GZIP decompression for module"
> >        select MODULE_DECOMPRESS
> >
> > config MODULE_DECOMPRESS_XZ
> >        bool "Support in-kernel XZ decompression for module"
> >        select MODULE_DECOMPRESS
> >
> > config MODULE_DECOMPRESS_ZSTD
> >        bool "Support in-kernel ZSTD decompression for module"
> >        select MODULE_DECOMPRESS
> >
> > config MODULE_DECOMPRESS
> >        bool
> >
> >
> >
> >
> > You can toggle MODULE_COMPRESS_GZIP and
> > MODULE_DECOMPRESS_GZIP independently
>
> I can implement this, but what would be a use case to enable multiple module
> decompression types in the kernel?


I just thought there is a possibility where the singer service A
compresses modules in GZIP, and the singer service B in XZ, etc.

If the compression type is predictable at the Kbuild time,
it is fine.




>
> >
> >
> > Of course, the current kernel/module/decompress.c does not
> > work when multiple (or zero) CONFIG_MODULE_DECOMPRESS_* is
> > enabled. It needs a little modification.
>
> One issue is with the file /sys/module/compression which shows the module
> decompression type supported by the kernel. If multiple types are allowed then
> I think they should all get listed there. This could however create some
> compatibility problems. For instance, kmod reads this file and currently
> expects to find exactly one type, so it would need updating as well.


OK, understood. Then,

Acked-by: Masahiro Yamada <masahiroy@...nel.org>



--
Best Regards
Masahiro Yamada