linux-kernel - Re: [PATCH Bugfix v2 2/4] x86/xsaves: Define and use user_xstate

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] [day] [month] [year] [list]

Message-ID: <5540E25F.20303@intel.com>
Date:	Wed, 29 Apr 2015 06:53:35 -0700
From:	Dave Hansen <dave.hansen@...el.com>
To:	Fenghua Yu <fenghua.yu@...el.com>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Asit K Mallick <asit.k.mallick@...el.com>,
	Glenn Williamson <glenn.p.williamson@...el.com>
CC:	linux-kernel <linux-kernel@...r.kernel.org>, x86 <x86@...nel.org>
Subject: Re: [PATCH Bugfix v2 2/4] x86/xsaves: Define and use user_xstate_size
 for xstate size in signal context

On 04/21/2015 09:51 PM, Fenghua Yu wrote:
> +static int copy_to_user_xstate(void __user *buf_fx, struct xsave_struct *xsave)

I was thinking about this a bit more.  I think uncompacting the xsave
state from the kernel buffer in to the user buffer in software is
probably a bad idea.

It would nice, eventually, to not need to memset() the entire xsave
state when we initialize it.  It could be a lot bigger some day, and we
might start to notice the memset() cost.  We can't do this unless we're
careful about copying uninitialized parts of the task xstate buffer out
to userspace.

The whole reason we've gone down this path is that we are
!user_has_fpu(), so there is no FPU state in the registers which we can
xsave directly.  Perhaps we should enable the FPU hardware, restore the
state to the registers (from the xstate buffer), and then use
xsave_user() to write the user xstate buffer.

This *might* even be faster.  But, it *is* a slow (and rare) path, so it
does not really matter what we do performance-wise.  What I've described
above should be a lot less code than what we've got now.  It makes the
hardware do the hard work.
--
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/