linux-kernel - Re: [PATCH v2 1/3] x86/ldt: Make modify

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 21 Jul 2015 21:22:30 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Brian Gerst <brgerst@...il.com>
Cc:	Andy Lutomirski <luto@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	"security@...nel.org" <security@...nel.org>,
	X86 ML <x86@...nel.org>, Borislav Petkov <bp@...en8.de>,
	Sasha Levin <sasha.levin@...cle.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	stable <stable@...r.kernel.org>
Subject: Re: [PATCH v2 1/3] x86/ldt: Make modify_ldt synchronous

On Tue, Jul 21, 2015 at 7:53 PM, Brian Gerst <brgerst@...il.com> wrote:
> On Tue, Jul 21, 2015 at 10:12 PM, Andy Lutomirski <luto@...capital.net> wrote:
>> On Tue, Jul 21, 2015 at 7:01 PM, Brian Gerst <brgerst@...il.com> wrote:
>>> On Tue, Jul 21, 2015 at 3:59 PM, Andy Lutomirski <luto@...nel.org> wrote:
>>>> modify_ldt has questionable locking and does not synchronize
>>>> threads.  Improve it: redesign the locking and synchronize all
>>>> threads' LDTs using an IPI on all modifications.
>>>
>>> What does this fix?  I can see sending an IPI if the LDT is
>>> reallocated, but on every update seems unnecessary.
>>>
>>
>> It prevents nastiness in which you're in user mode with an impossible
>> CS or SS, resulting in potentially interesting artifacts in
>> interrupts, NMIs, etc.
>
> By impossible, do you mean a partially updated descriptor when the
> interrupt occurs?  Would making sure that the descriptor is atomically
> updated (using set_64bit()) fix that?
>

I tried to exploit that once and didn't get very far.  If I could
cause the LDT to be populated one bit at a time, I think I could
materialize a call gate out of thin air.  The docs are unclear on
what, if anything, the memory ordering rules are.

I'm more concerned about the case where a segment register caches a
value that is no longer in the LDT.  If it's DS, ES, FS, or GS, it
results in nondeterministic behavior but is otherwise not a big deal.
If it's CS or SS, then an interrupt or exception will write a stack
frame with the selectors but IRET can fault.

If the interrupt is an NMI and certain other conditions are met and
your kernel is older than 4.2-rc3, then you should read the
CVE-2015-5157 advisory I'll send tomorrow :)  Even on 4.2-rc3, the NMI
code still struggles a bit if this happens.

With this patch, you can never be in user mode with CS or SS selectors
that point at the LDT but don't match the LDT.  That makes me a lot
more comfortable with modify_ldt.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/