From: "H. Peter Anvin" <hpa@zytor.com>
To: Andy Lutomirski <luto@amacapital.net>,
Brian Gerst <brgerst@gmail.com>, Ingo Molnar <mingo@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
stable@vger.kernel.org, "H. Peter Anvin" <hpa@linux.intel.com>
Subject: Re: [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels
Date: Fri, 11 Apr 2014 14:24:37 -0700 [thread overview]
Message-ID: <53485D95.9030301@zytor.com> (raw)
In-Reply-To: <53485BB8.1000106@mit.edu>
On 04/11/2014 02:16 PM, Andy Lutomirski wrote:
> On 04/11/2014 11:29 AM, H. Peter Anvin wrote:
>> On 04/11/2014 11:27 AM, Brian Gerst wrote:
>>> Is this bug really still present in modern CPUs? This change breaks
>>> running 16-bit apps in Wine. I have a few really old games I like to
>>> play on occasion, and I don't have a copy of Win 3.11 to put in a VM.
>>
>> It is not a bug, per se, but an architectural definition issue, and it
>> is present in all x86 processors from all vendors.
>>
>> Yes, it does break running 16-bit apps in Wine, although Wine could be
>> modified to put 16-bit apps in a container. However, this is at best a
>> marginal use case.
>
> I wonder if there's an easy-ish good-enough fix:
>
> Allocate some percpu space in the fixmap. (OK, this is ugly, but
> kvmclock already does it, so it's possible.) To return to 16-bit
> userspace, make sure interrupts are off, copy the whole iret descriptor
> to the current cpu's fixmap space, change rsp to point to that space,
> and then do the iret.
>
> This won't restore the correct value to the high bits of [er]sp, but it
> will at least stop leaking anything interesting to userspace.
>
This would fix the infoleak, at the cost of allocating a chunk of memory
for each CPU. It doesn't fix the functionality problem.
If we're going to do a workaround I would prefer to do something that
fixes both, but it is highly nontrivial.
This is a writeup I did to a select audience before this was public:
> Hello,
>
> It appears we have an information leak on x86-64 by which at least bits
> [31:16] of the kernel stack address leaks to user space (some silicon
> including the 64-bit Pentium 4 leaks [63:16]). This is due to the the
> behavior of IRET when returning to a 16-bit segment: IRET restores only
> the bottom 16 bits of the stack pointer.
>
> This is known on 32 bits and we, in fact, have a workaround for it
> ("espfix") there. We do not, however, have the equivalent on 64 bits,
> nor does it seem that it is very easy to construct a workaround (see below.)
>
> This is both a functionality problem (16-bit code gets the upper bits of
> %esp corrupted when the kernel is invoked) and an information leak. The
> 32-bit workaround was labeled as a fix for the functionality problem,
> but it of course also addresses the leak.
>
> On 64 bits, the easiest mitigation seems to be to make modify_ldt()
> refuse to install a 16-bit segment when running on a 64-bit kernel.
> 16-bit support is already somewhat crippled on 64 bits since there is no
> V86 support; obviously, for "full service" support we can always set up
> a virtual machine -- most (but sadly, not all) 64-bit parts are also
> virtualization capable.
>
> I would have suggested rejecting modify_ldt() entirely, to reduce attack
> surface, except that some early versions of 32-bit NPTL glibc use
> modify_ldt() to exclusion of all other methods of establishing the
> thread pointer, so in order to stay compatible with those we would need
> to allow 32-bit segments via modify_ldt() still.
>
> However, there is no doubt this will break some legitimate users of
> 16-bit segments, e.g. Wine for 16-bit Windows apps (which don't work on
> 64-bit Windows either, for what it is worth.)
>
> We may very well have other infoleaks that dwarf this, but the kernel
> stack address is a relatively high value item for exploits.
>
> Some workarounds I have considered:
>
> a. Using paging in a similar way to the 32-bit segment base workaround
>
> This one requires a very large swath of virtual user space (depending on
> allocation policy, as much as 4 GiB per CPU.) The "per CPU" requirement
> comes in as locking is not feasible -- as we return to user space there
> is nowhere to release the lock.
>
> b. Return to user space via compatibility mode
>
> As the kernel lives above the 4 GiB virtual mark, a transition through
> compatibility mode is not practical. This would require the kernel to
> reserve virtual address space below the 4 GiB mark, which may interfere
> with the application, especially an application launched as a 64-bit
> application.
>
> c. Trampoline in kernel space
>
> A trampoline in kernel space is not feasible since all ring transition
> instructions capable of returning to 16-bit mode require the use of the
> stack.
>
> d. Trampoline in user space
>
> A return to the vdso with values set up in registers r8-r15 would enable
> a trampoline in user space. Unfortunately there is no way
> to do a far JMP entirely with register state so this would require
> touching user space memory, possibly in an unsafe manner.
>
> The most likely variant is to use the address of the 16-bit user stack
> and simply hope that this is a safe thing to do.
>
> This appears to be the most feasible workaround if a workaround is
> deemed necessary.
>
> e. Transparently run 16-bit code segments inside a lightweight VMM
>
> The complexity of this solution versus the realized value is staggering.
> It also doesn't work on non-virtualization-capable hardware (including
> running on top of a VMM which doesn't support nested virtualization.)
>
> -hpa
next prev parent reply other threads:[~2014-04-11 21:25 UTC|newest]
Thread overview: 137+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-11 17:36 [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels tip-bot for H. Peter Anvin
2014-04-11 18:12 ` Andy Lutomirski
2014-04-11 18:20 ` H. Peter Anvin
2014-04-11 18:27 ` Brian Gerst
2014-04-11 18:29 ` H. Peter Anvin
2014-04-11 18:35 ` Brian Gerst
2014-04-11 21:16 ` Andy Lutomirski
2014-04-11 21:24 ` H. Peter Anvin [this message]
2014-04-11 21:53 ` Andy Lutomirski
2014-04-11 21:59 ` H. Peter Anvin
2014-04-11 22:15 ` Andy Lutomirski
2014-04-11 22:18 ` H. Peter Anvin
2014-04-13 4:20 ` H. Peter Anvin
2014-04-12 23:26 ` Alexander van Heukelum
2014-04-12 23:31 ` H. Peter Anvin
2014-04-12 23:49 ` Alexander van Heukelum
2014-04-13 0:03 ` H. Peter Anvin
2014-04-13 1:25 ` Andy Lutomirski
2014-04-13 1:29 ` Andy Lutomirski
2014-04-13 3:00 ` H. Peter Anvin
2014-04-11 21:34 ` Linus Torvalds
2014-04-11 18:41 ` Linus Torvalds
2014-04-11 18:45 ` Brian Gerst
2014-04-11 18:50 ` Linus Torvalds
2014-04-12 4:44 ` Brian Gerst
2014-04-12 17:18 ` H. Peter Anvin
2014-04-12 19:35 ` Borislav Petkov
2014-04-12 19:44 ` H. Peter Anvin
2014-04-12 20:11 ` Borislav Petkov
2014-04-12 20:34 ` Brian Gerst
2014-04-12 20:59 ` Borislav Petkov
2014-04-12 21:13 ` Brian Gerst
2014-04-12 21:40 ` Borislav Petkov
2014-04-14 7:21 ` Ingo Molnar
2014-04-14 9:44 ` Borislav Petkov
2014-04-14 9:47 ` Ingo Molnar
2014-04-12 21:53 ` Linus Torvalds
2014-04-12 22:25 ` H. Peter Anvin
2014-04-13 2:56 ` Andi Kleen
2014-04-13 3:02 ` H. Peter Anvin
2014-04-13 3:13 ` Linus Torvalds
2014-04-12 20:29 ` Brian Gerst
2014-04-14 7:48 ` Alexandre Julliard
2014-05-07 9:18 ` Sven Joachim
2014-05-07 10:18 ` Borislav Petkov
2014-05-07 16:57 ` Linus Torvalds
2014-05-07 17:09 ` H. Peter Anvin
2014-05-07 17:50 ` Alexandre Julliard
2014-05-08 6:43 ` Sven Joachim
2014-05-08 13:50 ` H. Peter Anvin
2014-05-08 20:13 ` H. Peter Anvin
2014-05-08 20:40 ` H. Peter Anvin
2014-05-12 13:16 ` Josh Boyer
2014-05-12 16:52 ` H. Peter Anvin
2014-05-14 23:43 ` [tip:x86/urgent] x86-64, modify_ldt: Make support for 16-bit segments a runtime option tip-bot for Linus Torvalds
2014-04-11 18:46 ` [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels H. Peter Anvin
2014-04-14 7:27 ` Ingo Molnar
2014-04-14 15:45 ` H. Peter Anvin
2014-04-13 2:54 ` Andi Kleen
2014-04-21 22:47 ` [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE* H. Peter Anvin
2014-04-21 23:19 ` Andrew Lutomirski
2014-04-21 23:29 ` H. Peter Anvin
2014-04-22 0:37 ` Andrew Lutomirski
2014-04-22 0:53 ` H. Peter Anvin
2014-04-22 1:06 ` Andrew Lutomirski
2014-04-22 1:14 ` H. Peter Anvin
2014-04-22 1:28 ` Andrew Lutomirski
2014-04-22 1:47 ` H. Peter Anvin
2014-04-22 1:53 ` Andrew Lutomirski
2014-04-22 11:23 ` Borislav Petkov
2014-04-22 14:46 ` Borislav Petkov
2014-04-22 16:03 ` Andrew Lutomirski
2014-04-22 16:10 ` H. Peter Anvin
2014-04-22 16:33 ` Andrew Lutomirski
2014-04-22 16:43 ` Linus Torvalds
2014-04-22 17:00 ` Andrew Lutomirski
2014-04-22 17:04 ` Linus Torvalds
2014-04-22 17:11 ` Andrew Lutomirski
2014-04-22 17:15 ` H. Peter Anvin
2014-04-23 9:54 ` One Thousand Gnomes
2014-04-23 15:53 ` H. Peter Anvin
2014-04-23 17:08 ` Andrew Lutomirski
2014-04-23 17:16 ` H. Peter Anvin
2014-04-23 17:25 ` Andrew Lutomirski
2014-04-23 17:28 ` H. Peter Anvin
2014-04-23 17:45 ` Andrew Lutomirski
2014-04-22 17:19 ` Linus Torvalds
2014-04-22 17:29 ` H. Peter Anvin
2014-04-22 17:46 ` Andrew Lutomirski
2014-04-22 17:59 ` H. Peter Anvin
2014-04-22 18:03 ` Brian Gerst
2014-04-22 18:06 ` H. Peter Anvin
2014-04-22 18:17 ` Brian Gerst
2014-04-22 18:51 ` H. Peter Anvin
2014-04-22 19:55 ` Brian Gerst
2014-04-22 20:17 ` H. Peter Anvin
2014-04-22 23:08 ` Brian Gerst
2014-04-22 23:39 ` Andi Kleen
2014-04-22 23:40 ` H. Peter Anvin
2014-04-22 17:11 ` H. Peter Anvin
2014-04-22 17:26 ` Borislav Petkov
2014-04-22 17:29 ` Andrew Lutomirski
2014-04-22 19:27 ` Borislav Petkov
2014-04-23 6:24 ` H. Peter Anvin
2014-04-23 8:57 ` Alexandre Julliard
2014-04-22 17:09 ` H. Peter Anvin
2014-04-22 17:20 ` Andrew Lutomirski
2014-04-22 17:24 ` H. Peter Anvin
2014-04-22 11:25 ` Borislav Petkov
2014-04-23 1:17 ` H. Peter Anvin
2014-04-23 1:23 ` Andrew Lutomirski
2014-04-23 1:42 ` H. Peter Anvin
2014-04-23 14:24 ` Boris Ostrovsky
2014-04-23 16:56 ` H. Peter Anvin
2014-04-28 13:04 ` Konrad Rzeszutek Wilk
2014-04-25 21:02 ` Konrad Rzeszutek Wilk
2014-04-25 21:16 ` H. Peter Anvin
2014-04-24 4:13 ` comex
2014-04-24 4:53 ` Andrew Lutomirski
2014-04-24 22:24 ` H. Peter Anvin
2014-04-24 22:31 ` Andrew Lutomirski
2014-04-24 22:37 ` H. Peter Anvin
2014-04-24 22:43 ` Andrew Lutomirski
2014-04-28 23:05 ` H. Peter Anvin
2014-04-28 23:08 ` H. Peter Anvin
2014-04-29 0:02 ` Andrew Lutomirski
2014-04-29 0:15 ` H. Peter Anvin
2014-04-29 0:20 ` Andrew Lutomirski
2014-04-29 2:38 ` H. Peter Anvin
2014-04-29 2:44 ` H. Peter Anvin
2014-04-29 3:45 ` H. Peter Anvin
2014-04-29 3:47 ` H. Peter Anvin
2014-04-29 4:36 ` H. Peter Anvin
2014-04-29 7:14 ` H. Peter Anvin
2014-04-25 12:02 ` Pavel Machek
2014-04-25 21:20 ` H. Peter Anvin
[not found] <CAM1qvvhTaChkceBawnZZKZYT6tURcVZQe3upq3dpn_S9wp0C-Q@mail.gmail.com>
2014-04-13 13:03 ` [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels Jan Janecek
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=53485D95.9030301@zytor.com \
--to=hpa@zytor.com \
--cc=brgerst@gmail.com \
--cc=hpa@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mingo@kernel.org \
--cc=stable@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).