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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CALCETrUcTKVw+ke0FuhgfE2d5MrxYJyN4fwkuHUJfGVyF0GiyQ@mail.gmail.com>
Date:	Fri, 14 Aug 2015 11:46:20 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
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:25 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> 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?)
>

Beats the crap out of me.  Presumably it's because no one ever cared
what happened if the selectors were in the GDT.  This makes me suspect
that no one has ever tested math emulation in combination with
set_thread_area.


> 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).

Oh, crap.  You're right, and I'm embarrassed that I missed that.

>
> 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?

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.  FPU_CS is thing:

#define FPU_CS            (*(unsigned short *) &(FPU_info->regs->cs))

so it's only the pm_address thing that's broken.

Sorry :(

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