All of lore.kernel.org
 help / color / mirror / Atom feed
From: tip-bot for Andy Lutomirski <tipbot@zytor.com>
To: linux-tip-commits@vger.kernel.org
Cc: mingo@kernel.org, tglx@linutronix.de, brgerst@gmail.com,
	torvalds@linux-foundation.org, bp@alien8.de, dvlasenk@redhat.com,
	luto@kernel.org, peterz@infradead.org, luto@amacapital.net,
	linux-kernel@vger.kernel.org, hpa@zytor.com
Subject: [tip:x86/asm] x86/tls: Synchronize segment registers in set_thread_area()
Date: Fri, 29 Apr 2016 03:51:06 -0700	[thread overview]
Message-ID: <tip-c9867f863e19dd07c6085b457f6775047924c3b5@git.kernel.org> (raw)
In-Reply-To: <27d119b0d396e9b82009e40dff8333a249038225.1461698311.git.luto@kernel.org>

Commit-ID:  c9867f863e19dd07c6085b457f6775047924c3b5
Gitweb:     http://git.kernel.org/tip/c9867f863e19dd07c6085b457f6775047924c3b5
Author:     Andy Lutomirski <luto@kernel.org>
AuthorDate: Tue, 26 Apr 2016 12:23:30 -0700
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Fri, 29 Apr 2016 11:56:42 +0200

x86/tls: Synchronize segment registers in set_thread_area()

The current behavior of set_thread_area() when it modifies a segment that is
currently loaded is a bit confused.

If CS [1] or SS is modified, the change will take effect on return
to userspace because CS and SS are fundamentally always reloaded on
return to userspace.

Similarly, on 32-bit kernels, if DS, ES, FS, or (depending on
configuration) GS refers to a modified segment, the change will take
effect immediately on return to user mode because the entry code
reloads these registers.

If set_thread_area() modifies DS, ES [2], FS, or GS on 64-bit kernels or
GS on 32-bit lazy-GS [3] kernels, however, the segment registers
will be left alone until something (most likely a context switch)
causes them to be reloaded.  This means that behavior visible to
user space is inconsistent.

If set_thread_area() is implicitly called via CLONE_SETTLS, then all
segment registers will be reloaded before the thread starts because
CLONE_SETTLS happens before the initial context switch into the
newly created thread.

Empirically, glibc requires the immediate reload on CLONE_SETTLS --
32-bit glibc on my system does *not* manually reload GS when
creating a new thread.

Before enabling FSGSBASE, we need to figure out what the behavior
will be, as FSGSBASE requires that we reconsider our behavior when,
e.g., GS and GSBASE are out of sync in user mode.  Given that we
must preserve the existing behavior of CLONE_SETTLS, it makes sense
to me that we simply extend similar behavior to all invocations
of set_thread_area().

This patch explicitly updates any segment register referring to a
segment that is targetted by set_thread_area().  If set_thread_area()
deletes the segment, then the segment register will be nulled out.

[1] This can't actually happen since 0e58af4e1d21 ("x86/tls:
    Disallow unusual TLS segments") but, if it did, this is how it
    would behave.

[2] I strongly doubt that any existing non-malicious program loads a
    TLS segment into DS or ES on a 64-bit kernel because the context
    switch code was badly broken until recently, but that's not an
    excuse to leave the current code alone.

[3] One way or another, that config option should to go away.  Yuck!

Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/27d119b0d396e9b82009e40dff8333a249038225.1461698311.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 arch/x86/kernel/tls.c | 42 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/arch/x86/kernel/tls.c b/arch/x86/kernel/tls.c
index 7fc5e84..9692a5e 100644
--- a/arch/x86/kernel/tls.c
+++ b/arch/x86/kernel/tls.c
@@ -114,6 +114,7 @@ int do_set_thread_area(struct task_struct *p, int idx,
 		       int can_allocate)
 {
 	struct user_desc info;
+	unsigned short __maybe_unused sel, modified_sel;
 
 	if (copy_from_user(&info, u_info, sizeof(info)))
 		return -EFAULT;
@@ -141,6 +142,47 @@ int do_set_thread_area(struct task_struct *p, int idx,
 
 	set_tls_desc(p, idx, &info, 1);
 
+	/*
+	 * If DS, ES, FS, or GS points to the modified segment, forcibly
+	 * refresh it.  Only needed on x86_64 because x86_32 reloads them
+	 * on return to user mode.
+	 */
+	modified_sel = (idx << 3) | 3;
+
+	if (p == current) {
+#ifdef CONFIG_X86_64
+		savesegment(ds, sel);
+		if (sel == modified_sel)
+			loadsegment(ds, sel);
+
+		savesegment(es, sel);
+		if (sel == modified_sel)
+			loadsegment(es, sel);
+
+		savesegment(fs, sel);
+		if (sel == modified_sel)
+			loadsegment(fs, sel);
+
+		savesegment(gs, sel);
+		if (sel == modified_sel)
+			load_gs_index(sel);
+#endif
+
+#ifdef CONFIG_X86_32_LAZY_GS
+		savesegment(gs, sel);
+		if (sel == modified_sel)
+			loadsegment(gs, sel);
+#endif
+	} else {
+#ifdef CONFIG_X86_64
+		if (p->thread.fsindex == modified_sel)
+			p->thread.fsbase = info.base_addr;
+
+		if (p->thread.gsindex == modified_sel)
+			p->thread.gsbase = info.base_addr;
+#endif
+	}
+
 	return 0;
 }
 

  reply	other threads:[~2016-04-29 10:52 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-26 19:23 [PATCH 0/8] x86: A round of x86 segmentation improvements Andy Lutomirski
2016-04-26 19:23 ` [PATCH 1/8] x86/asm: Stop depending on ptrace.h in alternative.h Andy Lutomirski
2016-04-29 10:48   ` [tip:x86/asm] " tip-bot for Andy Lutomirski
2016-04-26 19:23 ` [PATCH 2/8] x86/asm: Make asm/alternative.h safe from assembly Andy Lutomirski
2016-04-29 10:49   ` [tip:x86/asm] " tip-bot for Andy Lutomirski
2016-04-26 19:23 ` [PATCH 3/8] x86/segments/64: When loadsegment(fs, ...) fails, clear the base Andy Lutomirski
2016-04-29 10:49   ` [tip:x86/asm] " tip-bot for Andy Lutomirski
2016-04-26 19:23 ` [PATCH 4/8] x86/segments/64: When load_gs_index " Andy Lutomirski
2016-04-29 10:49   ` [tip:x86/asm] " tip-bot for Andy Lutomirski
2016-04-26 19:23 ` [PATCH 5/8] x86/arch_prctl/64: Remove FSBASE/GSBASE < 4G optimization Andy Lutomirski
2016-04-26 20:50   ` Andi Kleen
2016-04-26 22:33     ` Andy Lutomirski
2016-04-29 10:50   ` [tip:x86/asm] " tip-bot for Andy Lutomirski
2016-04-26 19:23 ` [PATCH 6/8] x86/asm/64: Rename thread_struct's fs and gs to fsbase and gsbase Andy Lutomirski
2016-04-29 10:50   ` [tip:x86/asm] " tip-bot for Andy Lutomirski
2016-04-26 19:23 ` [PATCH 7/8] x86/tls: Synchronize segment registers in set_thread_area Andy Lutomirski
2016-04-29 10:51   ` tip-bot for Andy Lutomirski [this message]
2016-04-26 19:23 ` [PATCH 8/8] selftests/x86/ldt_gdt: Test set_thread_area deletion of an active segment Andy Lutomirski
2016-04-29 10:51   ` [tip:x86/asm] selftests/x86/ldt_gdt: Test set_thread_area() " tip-bot for Andy Lutomirski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=tip-c9867f863e19dd07c6085b457f6775047924c3b5@git.kernel.org \
    --to=tipbot@zytor.com \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=dvlasenk@redhat.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --subject='Re: [tip:x86/asm] x86/tls: Synchronize segment registers in set_thread_area()' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.