linux-kernel - [RFC v2 0/8] x86, xsave: rework of extended state handling, LWP support

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, 23 Mar 2011 16:27:39 +0100
From:	Hans Rosenfeld <hans.rosenfeld@....com>
To:	<hpa@...or.com>, <tglx@...utronix.de>, <mingo@...e.hu>
CC:	<x86@...nel.org>, <linux-kernel@...r.kernel.org>,
	<brgerst@...il.com>, <suresh.b.siddha@...el.com>,
	<eranian@...gle.com>, <robert.richter@....com>,
	<Andreas.Herrmann3@....com>,
	Hans Rosenfeld <hans.rosenfeld@....com>
Subject: [RFC v2 0/8] x86, xsave: rework of extended state handling, LWP support

Changes since last patch set:
* fixed race in signal return path that could lead to xstate corruptions
* avoid LWP state inconsitency after signal return by disabling LWP
  when entering a signal handler


This patch set is a general cleanup and rework of the code related to
handling of FPU and other extended states.

All handling of extended states, including the FPU state, is now handled
by xsave/xrstor wrappers that fall back to fxsave/fxrstor, or even
fsave/frstor, if hardware support for those features is lacking.

Non-lazy xstates, which cannot be restored lazily, can now be easily
supported with almost no processing overhead. This makes adding basic
support for AMDs LWP almost trivial.

Since non-lazy xstates are inherently incompatible with lazy allocation
of the xstate area, the complete removal of lazy allocation to further
reduce code complexity should be considered. Since SSE-optimized library
functions are widely used today, most processes will have an xstate area
anyway, so the memory overhead wouldn't be big enough to be much of an
issue.


Hans Rosenfeld (8):
  x86, xsave: cleanup fpu/xsave support
  x86, xsave: rework fpu/xsave support
  x86, xsave: cleanup fpu/xsave signal frame setup
  x86, xsave: remove unused code
  x86, xsave: more cleanups
  x86, xsave: add support for non-lazy xstates
  x86, xsave: add kernel support for AMDs Lightweight Profiling (LWP)
  x86, xsave: remove lazy allocation of xstate area

 arch/x86/ia32/ia32_signal.c        |    4 +-
 arch/x86/include/asm/i387.h        |  243 ++++++++--------------------
 arch/x86/include/asm/msr-index.h   |    1 +
 arch/x86/include/asm/processor.h   |   12 ++
 arch/x86/include/asm/sigcontext.h  |   12 ++
 arch/x86/include/asm/thread_info.h |    4 +-
 arch/x86/include/asm/xsave.h       |  100 +++----------
 arch/x86/kernel/i387.c             |  310 ++++--------------------------------
 arch/x86/kernel/process_32.c       |   29 ++---
 arch/x86/kernel/process_64.c       |   28 +---
 arch/x86/kernel/signal.c           |    4 +-
 arch/x86/kernel/traps.c            |   47 +-----
 arch/x86/kernel/xsave.c            |  311 +++++++++++++++++++++++-------------
 arch/x86/kvm/vmx.c                 |    2 +-
 arch/x86/kvm/x86.c                 |   11 +-
 arch/x86/math-emu/fpu_entry.c      |    8 +-
 drivers/lguest/x86/core.c          |    2 +-
 17 files changed, 380 insertions(+), 748 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/