linux-kernel - Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH

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:   Fri, 1 Oct 2021 09:51:17 -0700
From:   Will McVicker <willmcvicker@...gle.com>
To:     Olof Johansson <olof@...om.net>
Cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Saravana Kannan <saravanak@...gle.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        Russell King <linux@...linux.org.uk>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Sylwester Nawrocki <s.nawrocki@...sung.com>,
        Tomasz Figa <tomasz.figa@...il.com>,
        Chanwoo Choi <cw00.choi@...sung.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Alessandro Zummo <a.zummo@...ertech.it>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        John Stultz <john.stultz@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Lee Jones <lee.jones@...aro.org>,
        "Cc: Android Kernel" <kernel-team@...roid.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
        linux-clk <linux-clk@...r.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        linux-rtc@...r.kernel.org, Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

On Fri, Oct 1, 2021 at 9:00 AM Olof Johansson <olof@...om.net> wrote:
>
> On Fri, Oct 1, 2021 at 4:59 AM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> >
> > Hi Olof,
> >
> > On Fri, Oct 1, 2021 at 7:36 AM Olof Johansson <olof@...om.net> wrote:
> > > A much more valuable approach would be to work towards being able to
> > > free up memory by un-probed drivers at the end of boot. That would
> > > possibly benefit all platforms on all architectures.
> >
> > We used to have such a functionality in arch/ppc (not arch/powerpc!),
> > where code/data could be tagged __prep, __chrp, or __pmac, to put it
> > in a special section, and to be freed with initdata when unused.  It
> > was removed in v2.6.15[1], as the savings weren't worth the hassle.
> > In a more fragmented space like arm the memory lost due to alignment
> > of the sections would be even more substantial.
>
> Yeah, the balance between per-platform code size and overall kernel
> code size shifted over time to a point where it wasn't as meaningful
> on ppc.
>
> > Another problem is to know when is the end of the boot, especially
> > with deferred probing.
>
> Most of this code either has a module_init() or an initcall that
> actually registers the drivers and/or probes for the platform and does
> the work.
>
> This means you can have a late equivalent hook/initcall that
> determines whether this path ended up being probed/used. If it wasn't,
> you can then unregister and flag the corresponding memory to be freed
> at the end, and would take out the heuristics and guessing on needing
> to do it automatically from the code path that's doing said freeing.
>
>
> -Olof

First off, I appreciate the constructive conversations and I
understand the ask here. So I'd like to close the "we don't want this"
and "this isn't possible" conversation. We have already proven
downstream that it is in fact possible to modularize these drivers on
other SoCs (mentioned earlier if you missed it) and I'd like to direct
the conversation towards verifying/testing here instead of negatively
arguing about how SoC vendors aren't upstreaming their drivers. I
think everyone understands that, but unfortunately I have no control
over that even though I would love everyone to work upstream directly.

I am fine with forcing these drivers to always be enabled in some form
upstream even though it doesn't really make much sense for a generic
kernel that will run on Qualcomm, Exynos, Mediatek, (you name it) SoC
devices. I thought about how to do this yesterday and wasn't able to
come up with a proper solution that didn't always force this driver to
be a module when CONFIG_MODULES is enabled.

For example, if I do this below, then we will be forcing all builds to
use CONFIG_XXX as a module if they want just one driver as a module.

config XXX
  tristate "blah blah" if COMPILE_TEST
  default m if (ARCH_XXX && MODULES)
  default ARCH_XXX

The best I was able to come up with was this below which would allow
the driver to be a module or built-in; however, obviously it lets you
disable it in EXPERT mode.

config XXX
  tristate "blah blah" if COMPILE_TEST || EXPERT
  default ARCH_XXX

Let me know if you have a better solution that doesn't force the
driver to be a module when CONFIG_MODULES=y. Saravana did propose a
MINIMUM_ARM64_GENERIC_KERNEL config that could solve this, but that
too was shot down.

Thanks,
Will