Messages in this thread | | | From | Andy Lutomirski <> | Date | Mon, 16 Nov 2020 15:06:08 -0800 | 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@oracle.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@oracle.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.
| |