linux-kernel - Re: [RFC v2 PATCH 6/7] x86/entry: get rid of ALLOC_PT_GPREGS_ON_STACK and SAVE_AND_CLEAR

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]

Message-ID: <CA+55aFwWDfzgfiJNQCZkrOd8uUXp13TupPhNYrKSeeXMY-dr2g@mail.gmail.com>
Date:   Thu, 8 Feb 2018 09:39:31 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     Dominik Brodowski <linux@...inikbrodowski.net>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        Dan Williams <dan.j.williams@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andi Kleen <ak@...ux.intel.com>,
        Andrew Lutomirski <luto@...nel.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Brian Gerst <brgerst@...il.com>,
        Denys Vlasenko <dvlasenk@...hat.com>,
        Borislav Petkov <bp@...en8.de>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [RFC v2 PATCH 6/7] x86/entry: get rid of ALLOC_PT_GPREGS_ON_STACK
 and SAVE_AND_CLEAR_REGS

On Thu, Feb 8, 2018 at 1:47 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
> So for those reasons I'm really tempted by the all around simplification offered
> by this series:
>
>    2 files changed, 62 insertions(+), 160 deletions(-)
>
> Basically in this specific case I'd like to turn the argument around,
> use this simpler design and put the burden of proof on the patches that
> want to _complicate it_ beyond this simple, straightforward model

You make a good argument.

If the only real downside is slightly bigger static footprint (but the
actual real dynamic I$ footprint is not really impacted), then let's
just go for the simpler code.

It really would be lovely if our entry asm was understandable to mere mortals.

               Linus