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]

Message-ID: <20080522205619.GB7998@linux-os.sc.intel.com>
Date:	Thu, 22 May 2008 13:56:19 -0700
From:	Suresh Siddha <suresh.b.siddha@...el.com>
To:	Mikael Pettersson <mikpe@...uu.se>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Suresh Siddha <suresh.b.siddha@...el.com>,
	Andi Kleen <andi@...stfloor.org>, mingo@...e.hu,
	tglx@...utronix.de, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, roland@...hat.com, 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

On Thu, May 22, 2008 at 10:57:03AM +0200, Mikael Pettersson wrote:
> H. Peter Anvin writes:
>  > Suresh Siddha wrote:
>  > > In short, for non-rt frames, they can check the reserved bits at the end
>  > > of fpstate frame and for rt-frames (perhaps even for 32bit rt frame handling)
>  > > apps can check for uc_flag aswell, for extended state presence. Is this
>  > > good enough?
>  > > 
>  > 
>  > Okay, trying to close on this :)
>  > 
>  > I would suggest using the uc_flag for the rt frames, and simply rely on 
>  > the OSXSAVE flag for non-rt signal frames.  It a rather sucky approach 
>  > (as previously discussed), but since any sane user of these fields (as 
>  > opposed to just relying on the kernel to save/restore) should use the 
>  > SIGINFO frames, I don't see a problem *as long as it's possible to get 
>  > the information* -- any solution which demands performance should just 
>  > turn on SIGINFO and be happy.
> 
> I don't have the luxury to unconditionally change non-rt signal delivery
> to rt signal delivery, but using uc_flags plus OSXSAVE or prctl() to
> announce these layout changes would work for us. Of course, any existing
> sigframe mangling (as opposed to just reading it) code must be updated
> to avoid breakage, but that's unavoidable.
> 
>  > The biggest potential problem with this that I see is that relying on 
>  > CPUID can mess with certain virtualization solutions.  Another option to 

hpa, What is the virtualization problem? Are you referring to perf problem?
As you noted, regular non-rt signal handlers won't need this cpuid check. It's
needed only for those who manually look at non-rt signal frames and interpret it.
And also, they can do this check only once and not everytime.

To me, prtcl() just seems to be an overkill.

While restoring from the user, kernel also need to find out what layout
the user is passing. So it's bi-directional. I prefer the same mechanism
(using cookies/magic numbers etc inaddition to uc_flags or cpuid checks) to
interpret the fpstate for both user/kernel.

ARM also seem to be using similar things while extending their ucontext_t,
with out other kernel interfaces to indicate the layout.

BTW, how come 32bit kernel doesn't have the X86_FXSR_MAGIC checks, while restoring
the extended fxsave data from _fpstate?

thanks,
suresh

>  > accomplish the same thing would be to have a system call (preferrably a 
>  > prctl, since it is at least in theory personality-dependent) to query 
>  > what information is included in the fpstate data - since it will always 
>  > be the same for any particular kernel.
>  > 
>  > Thoughts?
> 
> Ok for me.
> 
> /Mikael
--
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/