linux-kernel - Re: [PATCH tip-pti 2/2] x86/entry: interleave XOR register clearing with PUSH/MOV instructions

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+55aFyXfMhUNoU9WveiMyKq32LftUGzF-BAP7hxEQOfwBTJrA@mail.gmail.com>
Date:   Tue, 6 Feb 2018 14:48:42 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Dominik Brodowski <linux@...inikbrodowski.net>
Cc:     Ingo Molnar <mingo@...nel.org>,
        Dan Williams <dan.j.williams@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andi Kleen <ak@...ux.intel.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andrew Lutomirski <luto@...nel.org>,
        "the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: [PATCH tip-pti 2/2] x86/entry: interleave XOR register clearing
 with PUSH/MOV instructions

On Tue, Feb 6, 2018 at 1:32 PM, Dominik Brodowski
<linux@...inikbrodowski.net> wrote:
> Same as is done for syscalls, interleave XOR with PUSH or MOV
> instructions for exceptions/interrupts, in order to minimize
> the cost of the additional instructions required for register
> clearing.

Side note: I would _really_ like to see

 (a) SAVE_{C,EXTRA}_REGS go away entirely, to be replaced by just SAVE_REGS.

     We never use them independently of each other any more.

 (b) Get rid of ALLOC_PT_GPREGS_ON_STACK entirely, and make SAVE_REGS
use pushq's instead of movs.

Doing (a) should be completely trivial.

Doing (b) looks like it needs _some_ care, because
ALLOC_PT_GPREGS_ON_STACK is not always done just before the SAVE_REGS,
the error entry code does it in in the early entry code. But honestly,
that seems mainly so that it can do

        testb   $3, CS(%rsp)                    /* If coming from
userspace, switch stacks */

before registers are saved, yet use the same CS offset as if they had
already been saved. So that _one_ stack offset in the 'idtentry' macro
would need to be fixed up.

There might be others that I don't see from just eyeballing, so it
does need some care, but wouldn't it be nice if *all* the entry code
could just use the same pushq sequences, and then put the xor's in
there?

The reason for that complexity is purely the system call fastpath case
that no longer exists, I think.

Am I missing something?

                Linus