linux-kernel - Re: [PATCH 3/4] kbuild: slim down package for building external modules

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <8bfa88b3-484e-4933-bc59-9dc12e37e691@quicinc.com>
Date: Fri, 28 Feb 2025 15:04:18 -0700
From: Jeffrey Hugo <quic_jhugo@...cinc.com>
To: Greg KH <gregkh@...uxfoundation.org>
CC: Nicolas Schier <n.schier@....de>, Masahiro Yamada <masahiroy@...nel.org>,
        <linux-kbuild@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        Kees Cook
	<kees@...nel.org>, Nathan Chancellor <nathan@...nel.org>,
        Ben Hutchings
	<ben@...adent.org.uk>, <regressions@...ts.linux.dev>
Subject: Re: [PATCH 3/4] kbuild: slim down package for building external
 modules

On 2/20/2025 10:43 AM, Greg KH wrote:
> On Thu, Feb 20, 2025 at 10:24:32AM -0700, Jeffrey Hugo wrote:
>> On 2/20/2025 9:49 AM, Greg KH wrote:
>>> What do you need/want to parse the .config file in the first place?  Why
>>> not rely on the generated .h files instead as those can be parsed the
>>> same way as before, right?
>>
>> Two usecases -
>>
>> First when secure boot is enabled, DKMS looks for CONFIG_MODULE_SIG_HASH to
>> figure out signing the modules so that they can be loaded.  Removing .config
>> causes an error in DKMS and the module signing process will fail.  The
>> resulting modules (already compiled successfully) will fail to load.
>> Whatever the user needed those modules for will no longer work.
> 
> Shouldn't the "normal" kbuild process properly sign the module if it
> needs to be signed?  Or are you trying to do this "by hand"?
> 
>> If the user is on Ubuntu, and has built a kernel 6.12 or later, they need to
>> build upstream DKMS and use it as none of the Canonical provided DKMS builds
>> have the fix.  This feels like a situation that would make the user afraid
>> to upgrade their kernel (to your point above).
>>
>> This feels very much like an "at runtime" issue, assuming external modules
>> are supported.  I may be wrong here.
> 
> external modules can be broken at any moment in time, you know that.
> There's never a guarantee for that at all.
> 
>> Second, our usecase is that we look at the .config to tell if a particular
>> driver is included in the kernel build (config =y or =m). This driver
>> provides diagnostic information which is useful to our product, but not
>> required for operation.  It does not have headers that are exposed to the
>> rest of the kernel, so checking the generated .h files does not work.  If
>> the driver is not built, we provide a backported version that is then built
>> out of tree.
> 
> You can check the same .h files for those config options, no need to
> manually parse a .config file.  What's wrong with including
> include/generated/autoconf.h properly?  That's what the build system
> uses, right?

I can't check .h files that don't exist.

However, I think your viewpoint is coming through pretty clear - we'll 
fix up what we can in our control, and I guess anything else gets 
dropped on the floor.  Seems like I have a conclusion.

-Jeff