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]
Message-ID: <CA+55aFwP6gJ5Qh7btvf_gME35nvR-se==MuRcvctDqdxEQ9SJA@mail.gmail.com>
Date:	Fri, 14 Aug 2015 11:25:15 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...nel.org>, Juergen Gross <jgross@...e.com>,
	Andy Lutomirski <luto@...nel.org>
Cc:	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 12:15 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
> Please pull the latest x86-urgent-for-linus git tree from:

Nope. It seems to be an unmitigated disaster, as far as I can tell.

> +static inline struct desc_struct FPU_get_ldt_descriptor(unsigned seg)
> +{
> +       static struct desc_struct zero_desc;
> +       struct desc_struct ret = zero_desc;
> +
> +#ifdef CONFIG_MODIFY_LDT_SYSCALL
> +       seg >>= 3;

So this seems to take the actual segment selector, and look it up in
the LDT. (Why only the LDT?)

However:

> +       descriptor = FPU_get_ldt_descriptor(segment);

as far as I can tell, the "segment" here is the segment _register_
number, not the segment selector.

The segment selector is in "addr->selector", and furthermore I'm not
at all convinced that it is in the LDT to begin with. I'd expect the
common case to be that it's in the GDT, in fact. But what do I know..

Anyway, I may be embarrassingly wrong, and if I am, feel free to shout
bad words at me, but that code seems to be utter crap.

Not that the old code was particularly good either, but at least that
PM_REG_(segment) that *used* to exist there would translate segment
register numbers into actual selector values (even if it would get the
FS case wrong).

Now that said, I doubt anybody cares. Since we don't support the
original 80386, the only way to ever trigger FP emulation is by having
a 486SX or possibly a couple of even rarer clone chips. So it's not
like the fact that the code is completely wrong and crap actually
*matters*, but I still refuse to pull stuff that seems to be so
completely screwed up.

And this commit is even marked as "reviewed". Are you guys really
seeing something that I'm not? Am I somehow wrong in thinking it's
entirely broken?

                       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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ