Messages in this thread | | | From | Thomas Gleixner <> | Subject | Re: [RFC][PATCH v2 00/21] x86/pti: Defer CR3 switch to C code | Date | Thu, 19 Nov 2020 20:32:42 +0100 |
| |
On Tue, Nov 17 2020 at 09:19, Alexandre Chartre wrote: > On 11/16/20 9:24 PM, Borislav Petkov wrote: >> On Mon, Nov 16, 2020 at 03:47:36PM +0100, Alexandre Chartre wrote: >> So PTI was added exactly to *not* have kernel memory mapped in the user >> page table. You're partially reversing that... > > We are not reversing PTI, we are extending it.
You widen the exposure surface without providing an argument why it is safe.
> PTI removes all kernel mapping from the user page-table. However there's > no issue with mapping some kernel data into the user page-table as long as > these data have no sensitive information.
Define sensitive information.
> Actually, PTI is already doing that but with a very limited scope. PTI adds > into the user page-table some kernel mappings which are needed for userland > to enter the kernel (such as the kernel entry text, the ESPFIX, the > CPU_ENTRY_AREA_BASE...). > > So here, we are extending the PTI mapping so that we can execute more kernel > code while using the user page-table; it's a kind of PTI on steroids.
Let's just look at a syscall:
noinstr long syscall_enter_from_user_mode(struct pt_regs *regs, long syscall) { long ret;
enter_from_user_mode(regs); lockdep_hardirqs_off(); user_exit_irqoff(); trace_hardirqs_off_finish();
So just looking at the 3 calls above, how are you going to guarantee that everything these callchains touch is mapped into user space?
Not to talk about everything which comes after that.
Thanks,
tglx
| |