linux-kernel - Re: [PATCH, RFC] x86-64: properly handle FPU code/data selectors

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:	Thu, 17 Oct 2013 08:09:07 +0100
From:	"Jan Beulich" <JBeulich@...e.com>
To:	"Linus Torvalds" <torvalds@...ux-foundation.org>
Cc:	"Ingo Molnar" <mingo@...e.hu>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	"KVM list" <kvm@...r.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH, RFC] x86-64: properly handle FPU code/data
 selectors

>>> On 16.10.13 at 20:43, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> So having looked at this some more, I would *really* prefer a
> different solution. The overwriting of the rip/rdp data just really
> annoys me.
> 
> Is there any reason to not just do it like the following instead:
> 
>  - get rid of the "word_size" thing, instead just add separate
> "fcs/fos" fields (that do *not* alias with rip/rdp).
> 
>  - on 64-bit, always use 64-bit ops, exactly the way we do now
> 
>  - if the resulting rip/rpd is zero in the high bits (and we have
> reason to believe the values exist at all, so X86_FEATURE_NO_FPU_SEL
> and the AMD test and/or checking that they aren't zero in the low bits
> too), do an *additional* fnstenv to the sstack, and then just save the
> resulting fcs/fos in the non-overlapping things. Use a simple helper
> function for this (that just gets called after the xsave/fxsave logic)

Up to here all is doable.

>  - same on restore.

But here things break: We can't do two successive restores, as
the second one would corrupt part of what the first one did. And
you surely don't suggest to copy the whole state into another
memory block first (in order to be able to alter the overlapping
fields)?

> No games. No "this is the word-size of the thing we've saved in
> memory". No overlapping "this field means one thing or another".
> 
> For signal handling, save/restore the new fop/fos thing, so that
> nobody ever sees the changed format, but FP state gets correctly and
> fully restored over signals too, not just kernel FP stuff.
> 
> Hmm? That would make me *much* happier, I suspect.

I realize that. But please don't forget that the problem by itself
is a result of no-one having cared about the selector portions
when having designed (a) the 64-bit architecture extension and
(b) the 64-bit Linux implementation, and I am only offering the
port of a solution taken from elsewhere. And I had suggested a
first, much different solution back in 2005/2006 (when there
was no sign of KVM yet, and hence just 32-bit processes
mattered) -
http://www.x86-64.org/pipermail/discuss/2005-December/007297.html
and
http://www.x86-64.org/pipermail/discuss/2006-April/008349.html.
To me it seemed always clear that it would be only a matter of
time until this issue transitions from theoretical to real.

(And for the record I also see it as problematic that 64-bit
[F]XSAVE store offsets instead of linear addresses, which
makes these fields close to useless when using operands
through fs:/gs: overrides; that's nothing the kernel can do
anything about though. It merely stretches that the 64-bit
extensions here weren't designed well in the first place, and
software now needs to play games to cover for that.)

Jan

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