linux-kernel - Re: [PATCH 1/2] x86_64_defconfig: Normalize x86

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] [day] [month] [year] [list]

Message-ID: <CAMuHMdWbS+AD4me1fT4yuzDGTp4piubTcQ_3UHP1nrbZ3YFyow@mail.gmail.com>
Date:   Wed, 4 Dec 2019 09:04:49 +0100
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Krzysztof Kozlowski <krzk@...nel.org>
Cc:     Enric Balletbo i Serra <enric.balletbo@...labora.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Collabora Kernel ML <kernel@...labora.com>,
        Guenter Roeck <groeck@...omium.org>,
        Benson Leung <bleung@...omium.org>,
        Dmitry Torokhov <dtor@...omium.org>,
        fabien.lahoudere@...labora.com,
        Guillaume Tucker <guillaume.tucker@...labora.com>,
        "H. Peter Anvin" <hpa@...or.com>, Borislav Petkov <bp@...en8.de>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "Ahmed S. Darwish" <darwish.07@...il.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Alexey Brodkin <alexey.brodkin@...opsys.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Ard Biesheuvel <ardb@...nel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Marek Szyprowski <m.szyprowski@...sung.com>
Subject: Re: [PATCH 1/2] x86_64_defconfig: Normalize x86_64 defconfig

Hi Krzysztof,

On Wed, Dec 4, 2019 at 2:15 AM Krzysztof Kozlowski <krzk@...nel.org> wrote:
> On Tue, 3 Dec 2019 at 18:01, Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> > On Tue, Dec 3, 2019 at 10:26 AM Krzysztof Kozlowski <krzk@...nel.org> wrote:
> > > On Tue, 3 Dec 2019 at 17:05, Enric Balletbo i Serra
> > > <enric.balletbo@...labora.com> wrote:
> > > > On 3/12/19 3:15, Krzysztof Kozlowski wrote:
> > > > > On Tue, 3 Dec 2019 at 05:18, Enric Balletbo i Serra
> > > > > <enric.balletbo@...labora.com> wrote:
> > > > >>
> > > > >> make savedefconfig result in some difference, lets normalize the
> > > > >> defconfig
> > > > >>
> > > > >
> > > > > No, for two reasons:
> > > > > 1. If running savedefconfig at all, split reordering items from
> > > > > removal of non needed options. This way we can see exactly what is
> > > > > being removed. This patch moves things around so it is not possible to
> > > > > understand what exactly you're doing here...
> > > >
> > > > Ok, makes sense, I can do it, but if you don't really care of having the
> > > > defconfig sync with the savedefconfig output for the below reasons or others,
> > > > that's fine with me.
> > > >
> > > > The reason I send the patch is because I think that, at least on some arm
> > > > defconfigs, they try to have the defconfig sync with the savedefconfig output,
> > > > the idea is to try to make patching the file easier, but I know this is usually
> > > > a pain.
> > >
> > > Till I saw DEBUG_FS removal and Steven's answer, I was all in in such
> > > patches from time to time. However now I think it's risky and instead
> > > manual cleanup of non-visible symbols is better.
> >
> > IMHO, it's the maintainer's responsibility to refresh the defconfig(s)
> > regularly, from known good config(s).
> >
> > I.e. you start from a known good .config, run "make oldconfig", verify
> > the changes by comparing the .config before/after, and run "make
> > savedefconfig" afterwards.
> >
> > You do not run blindly "make <my>_defconfig && make savedefconfig", as
> > that means you'll miss out on new options you may want, and will loose
> > old options that are no longer selected by other options.
>
> Instead of keeping this known good config somewhere outside it should
> be just equal to defconfig. There is no point to trim it with
> savedefconfig and then later experience missing options (because some
> option was a dependency but now is not). Instead, all visible options
> (possible to select) should be explicitly defined by defconfig to
> avoid what happened with DEBUG_FS.

While I agree that would fix the issue, it would revert to the situation
before we had savedefconfig. Hence it would cause much more churn to the
checked-in defconfig files, which is the reason why savedefconfig was
introduced in the first place....

> I assume here that when removing
> non-visible options from dependency, all defconfigs would be updated.

I'm afraid that part will never happen...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds