linux-kernel - Re: [GIT PULL] x86/boot changes for v5.7

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:   Tue, 31 Mar 2020 10:36:51 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Borislav Petkov <bp@...en8.de>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] x86/boot changes for v5.7

On Tue, Mar 31, 2020 at 12:53 AM Ingo Molnar <mingo@...nel.org> wrote:
>
>       x86/*/Makefile: Use -fno-asynchronous-unwind-tables to suppress .eh_frame sections

Ugh.

Looking at that commit, wouldn't it be better to try to move in a
direction where the special 32-bit code (or other stub code) simply
uses the actual KBUILD_CFLAGS as a base for what they do.

For example, in that EFI case, arm64 seems to do things the right way,
and this is literally the x86 code being inferior.

Both 32-bit and 64-bit arm seem to just filter out the flags that
don't work for it the stub code.

And honestly, that seems to be the *much* better approach.

The x86 approach is just rewriting the the cflags from scratch
inevitably has these kinds of odd special cases they it misses.

Wouldn't it be much better to try to standardize around that arm model instead?

I've pulled this, but it hurts to see these kinds of magical hackery.

              Linus