linux-kernel - Re: [RFC] x86: xsave/xrstor support, ucontext

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, 21 May 2008 17:47:52 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Suresh Siddha <suresh.b.siddha@...el.com>,
	Mikael Pettersson <mikpe@...uu.se>, mingo@...e.hu,
	tglx@...utronix.de, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, drepper@...hat.com,
	Hongjiu.lu@...el.com, linux-kernel@...r.kernel.org,
	arjan@...ux.intel.com, rmk+lkml@....linux.org.uk, dan@...ian.org,
	asit.k.mallick@...el.com
Subject: Re: [RFC] x86: xsave/xrstor support, ucontext_t extensions

> 1. potential information leak out of the kernel if the memory area isn't 
> zeroed before the first FXSAVE - I haven't verified if so is the case. 
> This would be a (potentially very serious) security hole.

Not a problem (see init_fpu).

> 2. Hidden state in the kernel - this means user space can set 
> nonarchitectural state in the kernel.  There are a few risks with that:
> 
>     a. Malware might use it to hide state.

Meh.  You can already use FP reg space when abusing non-FP-using programs
(via ptrace or signal frame clobbering).  Via ptrace, you can use %db[0-3]
without setting %db7 to make them affect hardware.  etc, etc.

>     b. The possibility of using the stability or lack thereof of this
>        state to extract information about kernel internals and/or
>        provide a covert channel in the presence of hardware changes.
>     c. It is not certain that future architectures will not have
>        off-limit fields here, like the equivalent of MXCSR.  This is
>        somewhat of a tricky judgement, of course, but it seems safer
>        to me if we would explicitly list the modifiable fields.

Meh.  The status quo is that (aside from initialization) it gets
whatever the hardware does.  FXRSTOR is an unprivileged instruction.
AFAIK the only reason we control the MXCSR value is because we don't
want to handle a #GP in context switch.  That would happen if reserved
bits were set in MXCSR.  We already have code to do fxrstor and handle
it, which sigreturn uses.  We could just use that if it weren't so
trivial to keep MXCSR safe--but since it is, why not keep one fewer
entry in the exception fixup table?

The hardware people know that it is unprivileged and is used in this way
where privileged code uses a data block received from unprivileged code.
If they add things that can make the data lead to new kinds of
exceptions, they will make it require the OS enable something, just like
we already have to set OSFXSR for the MXCSR reserved bits #GP case to be
possible.

Any piece of software state we start using in this buffer just has to
meet these same expectations.  (i.e. if any value could cause lossage to
anything but the user's own memory and user-mode CPU state, then we have
to police it at sigreturn/user_regset.set time.)

Thanks,
Roland
--
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/