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

[Andy Lutomirski]

On Mon, Nov 16, 2020 at 12:18 PM Alexandre Chartre
<alexandre.chartre@xxxxxxxxxx> wrote:
>
>
> On 11/16/20 8:48 PM, Andy Lutomirski wrote:
> > On Mon, Nov 16, 2020 at 6:49 AM Alexandre Chartre
> > <alexandre.chartre@xxxxxxxxxx> 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.