linux-kernel - Re: [PATCH] x86/tools/relocs: Add _etext and __end_of_kernel_reserve to S

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:   Mon, 13 Jan 2020 12:59:38 -0500
From:   Arvind Sankar <nivedita@...m.mit.edu>
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, Kees Cook <keescook@...omium.org>,
        Thomas Lendacky <Thomas.Lendacky@....com>,
        Michael Matz <matz@...e.de>
Subject: Re: [PATCH] x86/tools/relocs: Add _etext and __end_of_kernel_reserve
 to S_REL

On Mon, Jan 13, 2020 at 05:38:55PM +0100, Borislav Petkov wrote:
> On Mon, Jan 13, 2020 at 11:13:10AM -0500, Arvind Sankar wrote:
> > How to reproduce is just "build with old binutils". I don't see it's
> > reasonable to include a tutorial on how to build the kernel with a
> > toolchain that's not installed in the default PATH, as part of the commit
> > message.
> 
> The point is that it should be clear that it should state whether it is
> something you trigger with some stock distro which has been shipping
> this way or it is something you've customly created. Huge difference.
> 
> So pls make sure that is clear from the commit message.
> 

How is "breaks with binutils before version 2.23" not clear enough? It
will break regardless of whether distro shipped v2.21 or you built
v2.21. I'm _not_ creating a custom binutils with my own patches
specifically to trigger this issue, it's stock binutils, as stock as you
can get it.

Do you really want me to say in the commit message "to reproduce, first
compile binutils-2.21 from source, then try to build the kernel with
it"? Including this information would make sense only if the problem
wasn't with stock binutils, but only with some specific distro's patched
version. _Then_ it would make sense to say something like "binutils
package v-xxx shipped with OpenSUSE v-yyy was broken, this commit works
around it". This is a problem with _any_ binutils-2.21, there's nothing
special about how you need to build it.