linux-kernel - Re: [PATCH v4 2/2] x86/purgatory: Make sure we fail the build if purgatory.ro has missing symbols

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:   Thu, 12 Mar 2020 14:34:30 +0100
From:   Hans de Goede <hdegoede@...hat.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Arvind Sankar <nivedita@...m.mit.edu>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H . Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 2/2] x86/purgatory: Make sure we fail the build if
 purgatory.ro has missing symbols

Hi,

On 3/12/20 1:50 PM, Borislav Petkov wrote:
> On Thu, Mar 12, 2020 at 12:58:24PM +0100, Hans de Goede wrote:
>> My version of this patch has already been tested this way. It is
> 
> Tested with kexec maybe but if the 0day bot keeps finding breakage, that
> ain't good enough.

Which is why I have been fixing the issues which the 0day bot finds,
but then I get complaints about reving the patch set to quickly...

>> 1. Things are already broken, my patch just exposes the brokenness
>> of some configs, it is not actually breaking things (well it breaks
>> the build, changing a silent brokenness into an obvious one).
> 
> As I already explained, that is not good enough.

Right, which as I already said is why I'm fixing those issues.

>> 2. I send out the first version of this patch on 7 October 2019, it
>> has not seen any reaction until now. So I'm sending out new versions
>> quickly now that this issue is finally getting some attention...
> 
> And that is never the right approach.

In my experience once a patch-set has a maintainers attention,
quickly fixing any issues found usually is the right approach.
Because then usually it can get merged quickly and both the maintainer
and I can move on to other stuff. I'm sorry if you are finding this
annoying.

> Maintainers are busy as hell so !urgent stuff gets to wait. Spamming
> them with more patchsets does not help - fixing stuff properly does.

I am trying to fix this properly, the reason the 0daybot is
complaining is because of pre-existing bugs, not because of issues
with my original patch.

If I was not trying to fix this properly I would have long dropped
this patch to the floor and moved on.

TBH I'm quite unhappy that I'm being "yelled" at now (or so it
feels) while all I'm doing is trying to fix a long standing issue :(

> So, to sum up: if Arvind's approach is the better one, then we should do
> that and s390 should be fixed this way too. And all tested. And we will
> remove the hurry element from it all since it has not been noticed so
> far so it is not urgent and we can take our time and fix it properly.
> 
> Ok?

No not ok, I'm doing my best to help make things better here and
in return I'm getting what feels as a bunch of negativity and that
is NOT ok!

Now as how to move forward with this, I suggest that:

1) We wait a bit to see if the 0daybot finds any more existing issues
which are exposed by my patch

2) Change my patch to check for missing symbols to use the approach
which Arvind has suggested

3) Check that "kexec -l <kernel>" + "kexec -e" still work

4) Post v6.

Does that work for you ?

Regards,

Hans