linux-kernel - Re: [PATCH 00/11] drm: Restore helper usability

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]

Date: Mon, 22 Apr 2024 20:23:36 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Geert Uytterhoeven" <geert@...ux-m68k.org>
Cc: "Jani Nikula" <jani.nikula@...ux.intel.com>,
 "Geert Uytterhoeven" <geert+renesas@...der.be>,
 "Maarten Lankhorst" <maarten.lankhorst@...ux.intel.com>,
 "Maxime Ripard" <mripard@...nel.org>,
 "Thomas Zimmermann" <tzimmermann@...e.de>, "Dave Airlie" <airlied@...il.com>,
 "Daniel Vetter" <daniel@...ll.ch>, dri-devel@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org,
 Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
 "Masahiro Yamada" <masahiroy@...nel.org>,
 linux-kbuild <linux-kbuild@...r.kernel.org>
Subject: Re: [PATCH 00/11] drm: Restore helper usability

On Mon, Apr 22, 2024, at 18:58, Geert Uytterhoeven wrote:
> On Mon, Apr 22, 2024 at 3:55 PM Arnd Bergmann <arnd@...db.de> wrote:
>> On Mon, Apr 22, 2024, at 15:28, Jani Nikula wrote:
>> Whereas this one is broken:
>>
>> config FEATURE_A
>>        tristate "user visible if I2C is enabled"
>>        depends on I2C
>>
>> config HELPER_B
>>        tristate # hidden
>>        select FEATURE_A
>>
>> config DRIVER
>>        tristate "This driver is broken if I2C is disabled"
>>        select HELPER_B
>
> So the DRIVER section should gain a "depends on I2C" statement.

That is of course the common workaround, but my point was
that nothing should ever 'select I2C' or any of the other
subsystems that are user visible.

> Yamada-san: would it be difficult to modify Kconfig to ignore symbols
> like DRIVER that select other symbols with unmet dependencies?
> Currently it already warns about that.
>
> Handling this implicitly (instead of the current explict "depends
> on") would have the disadvantage though: a user who is not aware of
> the implicit dependency may wonder why DRIVER is invisible in his
> config interface.

I think hiding this would make it much harder to get anything
right. The symbols in question are almost all ones that should
be enabled in normal configs, and the 'make menuconfig' help
doesn't make it too hard to figure things out normally, we just
have to find a way to avoid regressions when converting things
to 'depends on' that used an incorrect 'select'.

     Arnd