linux-kernel - Re: [RFC][PATCH v2 11/21] x86/pti: Extend PTI user mappings

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: <CALCETrXYP13pPcRfDDkwetLgzA3quYOBg7OTo5nbpLpPfSqaLw@mail.gmail.com>
Date:   Mon, 16 Nov 2020 15:06:08 -0800
From:   Andy Lutomirski <luto@...nel.org>
To:     Alexandre Chartre <alexandre.chartre@...cle.com>
Cc:     Andy Lutomirski <luto@...nel.org>,
        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>,
        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 11/21] x86/pti: Extend PTI user mappings

On Mon, Nov 16, 2020 at 12:18 PM Alexandre Chartre
<alexandre.chartre@...cle.com> wrote:
>
>
> On 11/16/20 8:48 PM, Andy Lutomirski wrote:
> > On Mon, Nov 16, 2020 at 6:49 AM Alexandre Chartre
> > <alexandre.chartre@...cle.com> wrote:
> >>
> >> Extend PTI user mappings so that more kernel entry code can be executed
> >> with the user page-table. To do so, we need to map syscall and interrupt
> >> entry code, per cpu offsets (__per_cpu_offset, which is used some in
> >> entry code), the stack canary, and the PTI stack (which is defined per
> >> task).
> >
> > Does anything unmap the PTI stack?  Mapping is easy, and unmapping
> > could be a pretty big mess.
> >
>
> No, there's no unmap. The mapping exists as long as the task page-table
> does (i.e. as long as the task mm exits). I assume that the task stack
> and mm are freed at the same time but that's not something I have checked.
>

Nope.  A multi-threaded mm will free task stacks when the task exits,
but the mm may outlive the individual tasks.  Additionally, if you
allocate page tables as part of mapping PTI stacks, you need to make
sure the pagetables are freed.  Finally, you need to make sure that
the PTI stacks have appropriate guard pages -- just doubling the
allocation is not safe enough.

My intuition is that this is going to be far more complexity than is justified.