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

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

Message-ID: <CAJKOXPfzYSJdVg_j7MPP14WOve0cJpF+NV2FWWhjGbUEwVWavw@mail.gmail.com>
Date:   Wed, 4 Dec 2019 09:15:12 +0800
From:   Krzysztof Kozlowski <krzk@...nel.org>
To:     Geert Uytterhoeven <geert@...ux-m68k.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

On Tue, 3 Dec 2019 at 18:01, Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
>
> Hi Krzysztof,
>
> 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. I assume here that when removing
non-visible options from dependency, all defconfigs would be updated.

Best regards,
Krzysztof