From: Thomas Gleixner <tglx@linutronix.de>
To: Andy Lutomirski <luto@kernel.org>
Cc: x86@kernel.org, LKML <linux-kernel@vger.kernel.org>,
Borislav Petkov <bp@alien8.de>, Brian Gerst <brgerst@gmail.com>,
David Laight <David.Laight@aculab.com>,
Kees Cook <keescook@chromium.org>,
Peter Zijlstra <peterz@infradead.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: x86/ldt: Prevent ldt inheritance on exec
Date: Fri, 8 Dec 2017 21:02:17 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.2.20.1712082055390.2301@nanos> (raw)
From: Thomas Gleixner <tglx@linutronix.de>
The LDT is inheritet independent of fork or exec, but that makes no sense
at all because exec is supposed to start the process clean.
The reason why this happens is that init_new_context_ldt() is called from
init_new_context() which obviously needs to be called for both fork() and
exec().
It would be surprising if anything relies on that behaviour, so it seems to
be safe to remove that misfeature.
Check whether current is in exec() and avoid the LDT clone if so.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
arch/x86/kernel/ldt.c | 6 +++++-
tools/testing/selftests/x86/ldt_gdt.c | 9 +++------
2 files changed, 8 insertions(+), 7 deletions(-)
--- a/arch/x86/kernel/ldt.c
+++ b/arch/x86/kernel/ldt.c
@@ -135,7 +135,11 @@ int init_new_context_ldt(struct task_str
mutex_init(&mm->context.lock);
old_mm = current->mm;
- if (!old_mm) {
+ /*
+ * No action if current is a kernel thread or exec() is in
+ * progress.
+ */
+ if (!old_mm || current->in_execve) {
mm->context.ldt = NULL;
return 0;
}
--- a/tools/testing/selftests/x86/ldt_gdt.c
+++ b/tools/testing/selftests/x86/ldt_gdt.c
@@ -627,13 +627,10 @@ static void do_multicpu_tests(void)
static int finish_exec_test(void)
{
/*
- * In a sensible world, this would be check_invalid_segment(0, 1);
- * For better or for worse, though, the LDT is inherited across exec.
- * We can probably change this safely, but for now we test it.
+ * Older kernel versions did inherit the LDT on exec() which is
+ * wrong because exec() starts from a clean state.
*/
- check_valid_segment(0, 1,
- AR_DPL3 | AR_TYPE_XRCODE | AR_S | AR_P | AR_DB,
- 42, true);
+ check_invalid_segment(0, 1);
return nerrs ? 1 : 0;
}
next reply other threads:[~2017-12-08 20:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-08 20:02 Thomas Gleixner [this message]
2017-12-08 21:38 ` Linus Torvalds
2017-12-08 21:49 ` Thomas Gleixner
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=alpine.DEB.2.20.1712082055390.2301@nanos \
--to=tglx@linutronix.de \
--cc=David.Laight@aculab.com \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®