linux-kernel - Re: [RFC][PATCH v2 12/21] x86/pti: Use PTI stack instead of trampoline stack

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: <CALCETrUSCwtR41CCo_cAQf_BwG7istH6fM=bxWh_VfOjSNFmSw@mail.gmail.com>
Date:   Mon, 16 Nov 2020 08:57:51 -0800
From:   Andy Lutomirski <luto@...nel.org>
To:     Alexandre Chartre <alexandre.chartre@...cle.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>, X86 ML <x86@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Andrew Lutomirski <luto@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Tom Lendacky <thomas.lendacky@....com>,
        Joerg Roedel <jroedel@...e.de>,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        jan.setjeeilers@...cle.com, Junaid Shahid <junaids@...gle.com>,
        oweisse@...gle.com, Mike Rapoport <rppt@...ux.vnet.ibm.com>,
        Alexander Graf <graf@...zon.de>, mgross@...ux.intel.com,
        kuzuno@...il.com
Subject: Re: [RFC][PATCH v2 12/21] x86/pti: Use PTI stack instead of
 trampoline stack

On Mon, Nov 16, 2020 at 6:47 AM Alexandre Chartre
<alexandre.chartre@...cle.com> wrote:
>
> When entering the kernel from userland, use the per-task PTI stack
> instead of the per-cpu trampoline stack. Like the trampoline stack,
> the PTI stack is mapped both in the kernel and in the user page-table.
> Using a per-task stack which is mapped into the kernel and the user
> page-table instead of a per-cpu stack will allow executing more code
> before switching to the kernel stack and to the kernel page-table.

Why?

I can't immediately evaluate how nasty the page table setup is because
it's not in this patch.  But AFAICS the only thing that this enables
is sleeping with user page tables.  Do we really need to do that?