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: <90416ccc-8537-489c-ac15-78aacbcb42b0@suse.com>
Date: Thu, 25 Jul 2024 14:59:30 +0200
From: Petr Pavlu <petr.pavlu@...e.com>
To: Masahiro Yamada <masahiroy@...nel.org>
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 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?

> 
> 
> 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.

Thanks,
Petr