On Fri, Aug 14, 2015 at 11:57 AM, Linus Torvalds
<torva...@linux-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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
