linux-kernel - Re: [GIT PULL] x86 fixes

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 14 Aug 2015 12:06:24 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Ingo Molnar <mingo@...nel.org>, Juergen Gross <jgross@...e.com>,
	Andy Lutomirski <luto@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Brian Gerst <brgerst@...il.com>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] x86 fixes

On Fri, Aug 14, 2015 at 11:57 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> That code seems fine to me (and explicitly errors out when it's not in
> the LDT). FPU_CS is actually the CS selector value.
>
> So testing that for being in the LDT by checking bit #2, and then
> using FPU_get_ldt_descriptor() on it actually seems *correct*.
>
> It's the actual instruction data segment handling that looks entirely
> broken, and was explicitly made *more* broken by that commit.

Note that in practice, it's *probably* true that if CS ends up being
in the LDT (so we're running something odd like Wine), then *probably*
the data segments are going to be in the LDT too. So the old code that
unconditionally looked things up in the LDT probably worked in
practice, even if it was wrong.

The new code cannot *possibly* work at all, because even if the data
segment register is in the LDT, it uses the wrong thing to look up the
LDT entry, so it will get the wrong base.

But as mentioned, it will only *matter* on something like a 486SX, and
only when the whole "CS/DS didn't match the default flat segments"
case triggers, so not only do you have to run on a 486SX, you will
have to run something like Wine on it. So it sounds very very unlikely
that this bug matters in practice.

                      Linus
--
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/