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> -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
