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, luto@kernel.org,
	torvalds@linux-foundation.org, hpa@zytor.com,
	peterz@infradead.org, linux-kernel@vger.kernel.org,
	bpetkov@suse.de
Subject: [tip:x86/asm] selftests/x86/ldt_gdt: Robustify against set_thread_area() and LAR oddities
Date: Tue, 7 Nov 2017 02:17:03 -0800	[thread overview]
Message-ID: <tip-d60ad744c9741586010d4bea286f09a063a90fbd@git.kernel.org> (raw)
In-Reply-To: <b82f3f89c034b53580970ac865139fd8863f44e2.1509794321.git.luto@kernel.org>

Commit-ID:  d60ad744c9741586010d4bea286f09a063a90fbd
Gitweb:     https://git.kernel.org/tip/d60ad744c9741586010d4bea286f09a063a90fbd
Author:     Andy Lutomirski <luto@kernel.org>
AuthorDate: Sat, 4 Nov 2017 04:19:49 -0700
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Tue, 7 Nov 2017 11:13:42 +0100

selftests/x86/ldt_gdt: Robustify against set_thread_area() and LAR oddities

Bits 19:16 of LAR's result are undefined, and some upcoming
improvements to the test case seem to trigger this.  Mask off those
bits to avoid spurious failures.

commit 5b781c7e317f ("x86/tls: Forcibly set the accessed bit in TLS
segments") adds a valid case in which LAR's output doesn't quite
agree with set_thread_area()'s input.  This isn't triggered in the
test as is, but it will be if we start calling set_thread_area()
with the accessed bit clear.  Work around this discrepency.

I've added a Fixes tag so that -stable can pick this up if neccesary.

Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bpetkov@suse.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: 5b781c7e317f ("x86/tls: Forcibly set the accessed bit in TLS segments")
Link: http://lkml.kernel.org/r/b82f3f89c034b53580970ac865139fd8863f44e2.1509794321.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 tools/testing/selftests/x86/ldt_gdt.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/x86/ldt_gdt.c b/tools/testing/selftests/x86/ldt_gdt.c
index 961e3ee..b033433 100644
--- a/tools/testing/selftests/x86/ldt_gdt.c
+++ b/tools/testing/selftests/x86/ldt_gdt.c
@@ -115,7 +115,15 @@ static void check_valid_segment(uint16_t index, int ldt,
 		return;
 	}
 
-	if (ar != expected_ar) {
+	/* The SDM says "bits 19:16 are undefined".  Thanks. */
+	ar &= ~0xF0000;
+
+	/*
+	 * NB: Different Linux versions do different things with the
+	 * accessed bit in set_thread_area().
+	 */
+	if (ar != expected_ar &&
+	    (ldt || ar != (expected_ar | AR_ACCESSED))) {
 		printf("[FAIL]\t%s entry %hu has AR 0x%08X but expected 0x%08X\n",
 		       (ldt ? "LDT" : "GDT"), index, ar, expected_ar);
 		nerrs++;

  reply	other threads:[~2017-11-07 10:20 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-04 11:19 [PATCH 0/5] Minor selftests improvements Andy Lutomirski
2017-11-04 11:19 ` [PATCH 1/5] selftests/x86/protection_keys: Fix syscall NR redefinition warnings Andy Lutomirski
2017-11-07 10:16   ` [tip:x86/asm] " tip-bot for Andy Lutomirski
2017-11-04 11:19 ` [PATCH 2/5] selftests/x86/ldt_gdt: Robustify against set_thread_area() and LAR oddities Andy Lutomirski
2017-11-07 10:17   ` tip-bot for Andy Lutomirski [this message]
2017-11-04 11:19 ` [PATCH 3/5] selftests/x86/ldt_gdt: Add infrastructure to test set_thread_area() Andy Lutomirski
2017-11-07 10:17   ` [tip:x86/asm] " tip-bot for Andy Lutomirski
2017-11-04 11:19 ` [PATCH 4/5] selftests/x86/ldt_gdt: Run most existing LDT test cases against the GDT as well Andy Lutomirski
2017-11-07 10:17   ` [tip:x86/asm] " tip-bot for Andy Lutomirski
2017-11-04 11:19 ` [PATCH 5/5] selftests/x86/ldt_get: Add a few additional tests for limits Andy Lutomirski
2017-11-07 10:18   ` [tip:x86/asm] " tip-bot for Andy Lutomirski
2017-11-07 10:13 ` [PATCH 0/5] Minor selftests improvements Ingo Molnar

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-d60ad744c9741586010d4bea286f09a063a90fbd@git.kernel.org \
    --to=tipbot@zytor.com \
    --cc=bpetkov@suse.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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 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.