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:	Fri, 14 Aug 2015 11:57:46 -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:46 AM, Andy Lutomirski <luto@...capital.net> wrote:
>
> I think it's only slightly broken.
>
> This bit:
>
>         if ((FPU_CS & 4) != 4) {    /* Must be in the LDT */
>             /* Can only handle segmented addressing via the LDT
>                for now, and it must be 16 bit */
>             printk("FPU emulator: Unsupported addressing mode\n");
>             math_abort(FPU_info, SIGILL);
>         }
>
>         code_descriptor = FPU_get_ldt_descriptor(FPU_CS);
>
> is buggy, but no buggier than the old code.

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.

The FPU emulation code has two different kinds of segment defines:

 - the PREFIX_xx_ defines are the segment register numbers (well,
prefix numbers)

 - the FPU_CS/SS/DS defines are the current selector values for those.

and yes, it's confusing how it tends to use the variable name
"segment" for the prefix number, when in the rest of the kernel we
tend to always track the selector value.

                 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