linux-kernel - Re: [PATCH tip:x86/mm] x86/tls: Forcibly set the accessed bit in TLS segments

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 21 Mar 2017 08:24:50 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Andy Lutomirski <luto@...capital.net>
Cc:     Andy Lutomirski <luto@...nel.org>, X86 ML <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Borislav Petkov <bp@...en8.de>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Thomas Garnier <thgarnie@...gle.com>
Subject: Re: [PATCH tip:x86/mm] x86/tls: Forcibly set the accessed bit in TLS
 segments


* Andy Lutomirski <luto@...capital.net> wrote:

> On Sat, Mar 18, 2017 at 10:17 PM, Andy Lutomirski <luto@...nel.org> wrote:
> > For mysterious historical reasons, struct user_desc doesn't indicate
> > whether segments are accessed.  set_thread_area() has always
> > programmed segments as non-accessed, so the first write will set the
> > accessed bit.  This will fault if the GDT is read-only.
> >
> > Fix it by making TLS segments start out accessed.
> >
> > If this ends up breaking something, we could, in principle, leave
> > TLS segments non-accessed and fix them up when we get the page
> > fault.  I'd be surprised, though -- AFAIK all the nasty legacy
> > segmented programs (DOSEMU, Wine, things that run on DOSEMU and
> > Wine, etc.) do their nasty segmented things using the LDT and not
> > the GDT.  I assume this is mainly because old OSes (Linux and
> > otherwise) didn't historically provide APIs to do nasty things in
> > the GDT.
> >
> > Fixes: 45fc8757d1d2 ("x86: Make the GDT remapping read-only on 64-bit")
> > Signed-off-by: Andy Lutomirski <luto@...nel.org>
> 
> FWIW, I'm now extra convinced that this won't break anything: the
> accessed bit didn't work properly before this patch.  When we
> scheduled a task in, we'd copy the TLS segment descriptors to the GDT,
> but we never copied them back out when we scheduled out, so the
> accessed bit would randomly clear itself.  Whoops :)
> 
> So arguably this patch would be a bugfix even without Thomas' changes.

It's probably even a small speedup per scheduling atom, as we'd avoid dirtying the 
GDT again and again, right?

On very high context switching rates it might even be measurable in principle, as 
this ought to be the only thing that dirtied the (per CPU) GDT cacheline, so if 
the workload is write bandwidth or store queue depth bound this change will 
slightly improve things.

Thanks,

	Ingo