Re: [PATCH 04/30] x86, kaiser: disable global pages by default with KAISER

[Thomas Gleixner]

On Wed, 8 Nov 2017, Dave Hansen wrote:
> From: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
> 
> Global pages stay in the TLB across context switches.  Since all
> contexts share the same kernel mapping, we use global pages to
> allow kernel entries in the TLB to survive when we context
> switch.
> 
> But, even having these entries in the TLB opens up something that
> an attacker can use [1].
> 
> Disable global pages so that kernel TLB entries are flushed when
> we run userspace. This way, all accesses to kernel memory result
> in a TLB miss whether there is good data there or not.  Without
> this, even when KAISER switches pages tables, the kernel entries
> might remain in the TLB.
> 
> We keep _PAGE_GLOBAL available so that we can use it for things
> that are global even with KAISER like the entry/exit code and
> data.

Just a nitpick which applies to a lot of the changelogs in this
series. Describing ourself (we) running/doing something is (understandable)
but not a really technical way to describe things. Aside of that some of
the descriptions are slightly convoluted. Let me rephrase the above
paragraphs:

 Global pages stay in the TLB across context switches.  Since all contexts
 share the same kernel mapping, these mappings are marked as global pages
 so kernel entries in the TLB are not flushed out on a context switch.
 
 But, even having these entries in the TLB opens up something that an
 attacker can use [1].

 That means that even when KAISER switches page tables on return to user
 space the global pages would stay in the TLB cache.

 Disable global pages so that kernel TLB entries can be flushed before
 returning to user space. This way, all accesses to kernel addresses from
 userspace result in a TLB miss independent of the existance of a kernel
 mapping.

 Replace _PAGE_GLOBAL by __PAGE_KERNEL_GLOBAL and keep _PAGE_GLOBAL
 available so that it can still be used for a few selected kernel mappings
 which must be visible to userspace, when KAISER is enabled, like the
 entry/exit code and data.

I admit it's a pet pieve, but having very precise changelogs for this kind
of changes makes review a lot easier and is really usefulwhen you have to
stare at a commit 3 month later.

Other than that:

Reviewed-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>