Re: [PATCH] x86/doc: add PTI description

[Dave Hansen]

>> +copy of the page tables which are used only when running userspace
>> +applications.  When the kernel is entered via syscalls, interrupts or
>> +exceptions, page tables are switched to the full "kernel" copy.  When
>> +the system switches back to user mode, the user copy is used again.
> 
> Uh, can userspace on one CPU attempt to observe kernelspace on the processor
> that is running kernel code?  I haven't read any of the published papers,
> so maybe I'm out in the woods here...

The paper basically shows how unprivileged userspace can figure out
where the kernel is located in memory, despite that location being random.

It's not observing another process or the kernel *running*.  It's just
finding where it *is*.

>> +When PTI is enabled, the kernel manages two sets of page
>> +tables.  The first copy is very similar to what would be present
>> +for a kernel without PTI.  This includes a complete mapping of
>> +userspace that the kernel can use for things like copy_to_user().
>> +
>> +The userspace copy is used when running userspace and mirrors the
>> +mapping of userspace present in the kernel copy.  It maps a only
>> +the kernel data needed to enter and exit the kernel.  This data
>> +is entirely contained in the 'struct cpu_entry_area' structure
>> +which is placed in the fixmap and thus each CPU's copy of the
>> +area has a compile-time-fixed virtual address.
> 
> Is that last sentence supposed to be a good thing?  Doesn't sound it
> to me...

It's a good thing, generally.  It makes it easy for a CPU to locate
*its* data.

>> +  g. On systems without PCID support, each CR3 write flushes
>> +     the entire TLB.  That means that each syscall, interrupt
>> +     or exception flushes the TLB.
> 
> Does this imply that PTI is best suited to CPUs that have PCID?

Yes, the performance properties are much less onerous on systems with PCID.