All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Andrei Vagin <avagin@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Dmitry Safonov <dsafonov@virtuozzo.com>,
	Cyrill Gorcunov <gorcunov@openvz.org>,
	Adam Borowski <kilobyte@angband.pl>,
	Andy Lutomirski <luto@kernel.org>,
	Thomas Garnier <thgarnie@google.com>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: linux-next: x86: Unalbe to run x32 processes on the x86_64 kernel
Date: Tue, 21 Mar 2017 07:45:39 +0100	[thread overview]
Message-ID: <20170321064539.GB30094@gmail.com> (raw)
In-Reply-To: <CANaxB-xWX+e9VdO4wJfC3Mr=spLNmd2Gyc7qTH6_L5PfY-qHRQ@mail.gmail.com>


* Andrei Vagin <avagin@gmail.com> wrote:

> Here is my bisect log:
> [avagin@laptop linux-next]$ git bisect log
> # bad: [f921b263d9602fb7873710c2df70671f2ffcf658] Add linux-next
> specific files for 20170320
> # good: [4495c08e84729385774601b5146d51d9e5849f81] Linux 4.11-rc2
> git bisect start 'HEAD' 'v4.11-rc2'
> # good: [adeec71e7b8a11ff44103cfa4e1c6002c27ae9ac] Merge
> remote-tracking branch 'drm/drm-next'
> git bisect good adeec71e7b8a11ff44103cfa4e1c6002c27ae9ac
> # bad: [e5b1cee1bb9d8a66b28d64db9d8250ae2b0803d2] Merge
> remote-tracking branch 'tty/tty-next'
> git bisect bad e5b1cee1bb9d8a66b28d64db9d8250ae2b0803d2
> # good: [81cde6aecf21113c6bc65bc944587db4cbd3f64d] Merge
> remote-tracking branch 'mmc/next'
> git bisect good 81cde6aecf21113c6bc65bc944587db4cbd3f64d
> # bad: [69d76288005784205678520826a74c28e49a1703] Merge
> remote-tracking branch 'tip/auto-latest'
> git bisect bad 69d76288005784205678520826a74c28e49a1703
> # good: [6d32edf2be6c4e0f08b102e2d3227278ebb477c9] Merge
> remote-tracking branch 'spi/for-next'
> git bisect good 6d32edf2be6c4e0f08b102e2d3227278ebb477c9
> # good: [61f63e383784bd0ab6529cfc95ddc59c713afcc9] Merge tag
> 'perf-core-for-mingo-4.12-20170316' of
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into
> perf/core
> git bisect good 61f63e383784bd0ab6529cfc95ddc59c713afcc9
> # good: [3069c5a046ec92dc552194686c95e27c8c9e919d] Merge branch 'x86/asm'
> git bisect good 3069c5a046ec92dc552194686c95e27c8c9e919d
> # bad: [5b804ec2fd3272385ba7530c3a67d7402fb6d8a0] Merge branch 'x86/mm'
> git bisect bad 5b804ec2fd3272385ba7530c3a67d7402fb6d8a0
> # good: [06c830a48346643e195801460dfe16d96ba4dff5] x86/power: Add
> 5-level paging support
> git bisect good 06c830a48346643e195801460dfe16d96ba4dff5
> # good: [2bbbd194fdca01f694e2ca3fb447a1acf9d19f76] Merge branch 'x86/cpu'
> git bisect good 2bbbd194fdca01f694e2ca3fb447a1acf9d19f76
> # good: [69218e47994da614e7af600bf06887750ab6657a] x86: Remap GDT
> tables in the fixmap section
> git bisect good 69218e47994da614e7af600bf06887750ab6657a
> # bad: [74c8ce958dbf0b64f198becb5d8aa93afb967438] Merge branch 'linus'
> into x86/mm, to pick up a bugfix
> git bisect bad 74c8ce958dbf0b64f198becb5d8aa93afb967438
> # bad: [45fc8757d1d2128e342b4e7ef39adedf7752faac] x86: Make the GDT
> remapping read-only on 64-bit
> git bisect bad 45fc8757d1d2128e342b4e7ef39adedf7752faac
> # first bad commit: [45fc8757d1d2128e342b4e7ef39adedf7752faac] x86:
> Make the GDT remapping read-only on 64-bit

Just wondering, does the following commit fix it:

  5b781c7e317f x86/tls: Forcibly set the accessed bit in TLS segments

?

Also attached below.

Thanks,

	Ingo

=================>
>From 5b781c7e317fcf9f74475dc82bfce2e359dfca13 Mon Sep 17 00:00:00 2001
From: Andy Lutomirski <luto@kernel.org>
Date: Sat, 18 Mar 2017 22:17:24 -0700
Subject: [PATCH] x86/tls: Forcibly set the accessed bit in TLS segments

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@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Thomas Garnier <thgarnie@google.com>
Link: http://lkml.kernel.org/r/62b7748542df0164af7e0a5231283b9b13858c45.1489900519.git.luto@kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/kernel/tls.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/tls.c b/arch/x86/kernel/tls.c
index 6c8934406dc9..dcd699baea1b 100644
--- a/arch/x86/kernel/tls.c
+++ b/arch/x86/kernel/tls.c
@@ -92,10 +92,17 @@ static void set_tls_desc(struct task_struct *p, int idx,
 	cpu = get_cpu();
 
 	while (n-- > 0) {
-		if (LDT_empty(info) || LDT_zero(info))
+		if (LDT_empty(info) || LDT_zero(info)) {
 			desc->a = desc->b = 0;
-		else
+		} else {
 			fill_ldt(desc, info);
+
+			/*
+			 * Always set the accessed bit so that the CPU
+			 * doesn't try to write to the (read-only) GDT.
+			 */
+			desc->type |= 1;
+		}
 		++info;
 		++desc;
 	}

  reply	other threads:[~2017-03-21  6:46 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-20 23:57 linux-next: x86: Unalbe to run x32 processes on the x86_64 kernel Andrei Vagin
2017-03-21  1:32 ` Adam Borowski
2017-03-21  5:17 ` Andrei Vagin
2017-03-21  6:45   ` Ingo Molnar [this message]
2017-03-21  7:59     ` Adam Borowski
2017-03-21 12:49       ` Thomas Gleixner
2017-03-21 12:50         ` Dmitry Safonov
2017-03-21 15:59           ` Dmitry Safonov
2017-03-21 16:28             ` 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=20170321064539.GB30094@gmail.com \
    --to=mingo@kernel.org \
    --cc=avagin@gmail.com \
    --cc=dsafonov@virtuozzo.com \
    --cc=gorcunov@openvz.org \
    --cc=hpa@zytor.com \
    --cc=kilobyte@angband.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=thgarnie@google.com \
    /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.