Messages in this thread | | | From | Andy Lutomirski <> | Date | Mon, 11 Dec 2017 08:01:09 -0800 | Subject | Re: [PATCH PTI v2 3/6] x86/vsyscall/64: Explicitly set _PAGE_USER in the pagetable hierarchy |
| |
On Mon, Dec 11, 2017 at 5:39 AM, Ingo Molnar <mingo@kernel.org> wrote: > > * Andy Lutomirski <luto@kernel.org> wrote: > >> The kernel is very erratic as to which pagetables have _PAGE_USER >> set. The vsyscall page gets lucky: it seems that all of the >> relevant pagetables are among the apparently arbitrary ones that set >> _PAGE_USER. Rather than relying on chance, just explicitly set >> _PAGE_USER. >> >> This will let us clean up pagetable setup to stop setting >> _PAGE_USER. The added code can also be reused by pagetable >> isolation to manage the _PAGE_USER bit in the usermode tables. >> >> Signed-off-by: Andy Lutomirski <luto@kernel.org> >> --- >> arch/x86/entry/vsyscall/vsyscall_64.c | 33 ++++++++++++++++++++++++++++++++- >> 1 file changed, 32 insertions(+), 1 deletion(-) > > Btw., would it make sense to clean up all this confusion? > > In particular a 'KERNEL' pre of post fix is ambiguous in this context I think, and > the PAGE_KERNEL_ prefix is actively harmful I think and is at the root of the > confusion. > > So if renamed it and used this nomenclature consistently instead: > > PAGE_USER_ > PAGE_SYSTEM_
Like _PAGE_USER_VSYSCALL?
Anyway, that's not the confusion I'm talking about. I'm talking about _KERNPG_TABLE vs _PAGE_TABLE. The latter should be called _USERPG_TABLE, and a whole bunch of its users should be switched to _KERNPG_TABLE.
But, since PTI is intended for backporting, I think these types of big cleanups should wait.
> > ... and got rid of PAGE_KERNEL uses in arch/x86/, then it would be obvious at > first glance what kind of mapping is established in a particular place - and it > would stay so in the future as well. > > ( There's some interaction with generic MM code which needs the original defines > like PAGE_KERNEL[_EXEC], but those generic masks could be defined as aliases, to > keep this cleanup within x86 for now. ) > > Thanks, > > Ingo
| |