lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 9 Nov 2017 23:19:31 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Dave Hansen <dave.hansen@...ux.intel.com>
cc:     linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        moritz.lipp@...k.tugraz.at, daniel.gruss@...k.tugraz.at,
        michael.schwarz@...k.tugraz.at, richard.fellner@...dent.tugraz.at,
        luto@...nel.org, torvalds@...ux-foundation.org,
        keescook@...gle.com, hughd@...gle.com, x86@...nel.org
Subject: Re: [PATCH 04/30] x86, kaiser: disable global pages by default with
 KAISER

On Wed, 8 Nov 2017, Dave Hansen wrote:
> From: Dave Hansen <dave.hansen@...ux.intel.com>
> 
> 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@...utronix.de>

Powered by blists - more mailing lists