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:	Wed, 16 Oct 2013 16:36:33 +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 17:19, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> On Wed, Oct 16, 2013 at 5:00 AM, Jan Beulich <JBeulich@...e.com> wrote:
>>
>> The basic idea here is to either use a priori information on the
>> intended state layout (in the case of 32-bit processes) or "sense" the
>> proper layout (in the case of KVM guests) by inspecting the already
>> saved FPU rip/rdp, and reading their actual values in a second save
>> operation.
> 
> The rip/rdp thing looks very hacky. And *without* the rip/rdp thing, I
> think the word-size always matches the TIF32 bit, right?

Correct. Which is why the "sensing" is done only when the word size
isn't known (i.e. in the case of running a KVM guest). This possibility
of avoiding the extra logic in the majority of cases is the main
difference to the Xen side solution (where we can bypass it only for
vCPU-s of 32-bit PV guests, which presumably isn't a majority).

> Why wouldn't the high bits be zero even in 64-bit mode? It would seem
> to be a *major* bug if you are in 64-bit mode but (for example) try to
> use the low 32-bit of virtual memory (ie something x32-like), and now
> your patch decides to use the 32-bit layout.
> 
> As far as I can tell, you actually corrupt rid/rdp in that case
> (because when you write the fcs thing, it overwrites the high bits of
> rip, and fos overwrites the high bits of rdp). So now bits that
> *should* be zero are not.
> 
> So you're basically trying to save some old state by corrupting new
> state instead.
> 
> Am I overlooking something?

In that case we use a 32-bit operand size [F]XRSTOR, and hence
the upper halves get treated as selectors, and the offsets get
zero-extended from the low halves, i.e. we preserve even more
state for such a 64-bit environment now too (albeit I doubt any
64-bit code actually cares). So if at all, copying the state out to
e.g. a signal context might need additional adjustment. That's the
main reason why I consider the patch RFC, i.e. possibly not ready
for being applied as is.

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/