linux-kernel - [RFC 0/2] FPU/xsave rework in preparation for LWP

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:	Tue, 23 Nov 2010 21:41:51 +0100
From:	Hans Rosenfeld <hans.rosenfeld@....com>
To:	<linux-kernel@...r.kernel.org>
CC:	<x86@...nel.org>, <brgerst@...il.com>, <robert.richter@....com>,
	<andreas.herrmann3@....com>,
	Hans Rosenfeld <hans.rosenfeld@....com>
Subject: [RFC 0/2] FPU/xsave rework in preparation for LWP

Hi,

please review and comment on these patches. They are based on tip/master
a17d38493c3dd2253828b107b5d405dd7cdcbf43. The first one is just a generic
cleanup of the xsave code that I already sent couple of weeks ago.

When my previous LWP patchset was reviewed I was told that it would be
much better to use only a single call to xsave and xrstor in the context
switch. This is basically what I try to achieve with the second patch:
base all "extended state" management on xsave/xrstor (with fallback to
fxsave/fxrstor or even fsave/frstor) and keep track of which extended
states a thread actually used. The actual LWP support is not included
here, I will work on this next. 

As a side effect of this rework, there will be a single simple interface
that can be used by other parts of the kernel that need to save and
restore extended states (thinking of KVM here). This should also improve
the general readability and maintainability of this code, although I
would agree that this isn't visible yet :)

There is a lot of room for cleaning things up here, which I will do
along with the LWP support. The LWP changes will require that each
thread will always have a xstate area, but I don't expect this to be
much of a problem. While this would add an overhead of around 1kb for
each thread that wouldn't need a xstate area otherwise, I expect that
there are only very few such threads on any reasonably modern system. I
will have to check that when the LWP support is done. This would allow
for another big cleanup by removing all the complexity of supporting
threads that don't have an xstate area.

Hans Rosenfeld (2):
  x86, xsave: cleanup xsave/xrstor support
  x86, xsave: rework xsave support

 arch/x86/include/asm/i387.h        |  111 +++++++----------------
 arch/x86/include/asm/thread_info.h |    2 +
 arch/x86/include/asm/xsave.h       |   88 ++++++++-----------
 arch/x86/kernel/i387.c             |   11 ++-
 arch/x86/kernel/process_64.c       |   24 +++---
 arch/x86/kernel/traps.c            |   31 +------
 arch/x86/kernel/xsave.c            |  174 +++++++++++++++++++-----------------
 arch/x86/kvm/x86.c                 |    7 +-
 8 files changed, 188 insertions(+), 260 deletions(-)

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