linux-kernel - Re: [GIT PULL 1/4] soc: driver updates for 6.11

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: <CACMJSetbuZ4u64fksB26AxMxYpiB2_i5=NJefDW_aN_-aHd62g@mail.gmail.com>
Date: Tue, 16 Jul 2024 22:15:55 +0200
From: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, soc@...nel.org
Subject: Re: [GIT PULL 1/4] soc: driver updates for 6.11

On Tue, 16 Jul 2024 at 21:53, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Mon, 15 Jul 2024 at 13:59, Arnd Bergmann <arnd@...db.de> wrote:
> >
> > soc: driver updates for 6.11
>
> Christ people, am I the only one actually testing any of this?
>

TBH it never occurred to me to test pure `make config`. I use `make
menuconfig` almost exclusively and never noticed this issue for that
reason.

> > Bartosz Golaszewski (14):
> >       firmware: qcom: add a dedicated TrustZone buffer allocator
>
> This causes me to get a new and COMPLETELY NONSENSICAL question on my
> regular AMD Threadripper workstation config.
>
> I'm getting quite fed up with all the constant complete disregard for
> any sanity in Kconfig files. People are putting in COMPLETE GARBAGE
> here, and apparently nobody bothers to test it for any kind of sanity.
>
> This kind of crap needs to stop.
>
> I think the fix is to just add a
>
>         depends on QCOM_TZMEM
>
> to that thing, but on my Altra machine even that doesn't fix this
> horror, because it turns out that everybody and their dog ends up
> doing
>
>         select QCOM_SCM
>
> and we have QCOM_SCM doing
>
>         select QCOM_TZMEM
>
> so it's hard as hell to actually get rid of that pointless churn,
> because you have to figure out which random driver ends up allegedly
> "needing" this.
>
> Are any of these actually _needed_? Because while I like automatic
> "select" things just picking the infrastructure that a driver actually
> requires to work, this all does *NOT* smell like "required
> infrastructure".
>
> This smells like random "do you actually want this?" to me.
>
> And the answer is "No. No I damn well do not". Particularly on my AMD
> machine that most definitely does not have some Qualcomm TrustZone
> thing.
>
>                 Linus

There's a patch from Geert already on the list[1] that should address this.

Bartosz

[1] https://lore.kernel.org/lkml/74947f7f132a811cc951749907b01bd25dcf23e6.1721135509.git.geert+renesas@glider.be/