linux-kernel - [PATCH Bugfix v2 0/4] x86/xsave/xsaves: Fix a few xsave/xsaves related bugs

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

Date:	Tue, 21 Apr 2015 21:51:55 -0700
From:	"Fenghua Yu" <fenghua.yu@...el.com>
To:	"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>,
	"Dave Hansen" <dave.hansen@...el.com>,
	"Glenn Williamson" <glenn.p.williamson@...el.com>
Cc:	"linux-kernel" <linux-kernel@...r.kernel.org>,
	"x86" <x86@...nel.org>, "Fenghua Yu" <fenghua.yu@...el.com>
Subject: [PATCH Bugfix v2 0/4] x86/xsave/xsaves: Fix a few xsave/xsaves related bugs

From: Fenghua Yu <fenghua.yu@...el.com>

This patchset is supposed to fix some xsave/xsaves related issues.

The patch 1/4 fixes an xstate offsets and sizes enumeration issue. During
enumerating offsets and sizes starting from 2 to the last enabled feature,
if one xstate's size is 0, current code thinks there is no other xstate
after this xstate and breaks from enumeration. This is not true because
architecturally it's possible to have a few xstates disabled between
xstate 2 and the last enabled xstate. The offsets and sizes of
the xstates that are not enumerated after the disabled xstate will be
consumed and cause issues in runtime.

The patch 2/4 introduces a new global variable "user_xstate_size". This
variable is used for standard formatted xsave area size in signal frame.
Current code incorrectly uses the smaller compacted formatted xsave area
size for signal frame and will cause issues in xstate access in signal
frame.

The patch 3/4 is not fixing a bug. But it renames "xstate_size" to
"kernel_xstate_size" to explicitly distinguish between xstate size in
kernel space and the one in user space. It just makes kernel code more
clear.

The patch 4/4 claims that the structure of xsave_struct is
non-architectural and fields/xstates in the structure is not defined
in compilation time. No new states should be added in xsave_struct.
The xsave area should be constructed during kernel booting time.

We may hit the issues on either existing platforms or upcoming platforms.
We had better to have the patches in upstream and backport them to stable
kernel and distros.

Fenghua Yu (4):
  x86/xsave.c: Fix xstate offsets and sizes enumeration
  x86/xsaves: Define and use user_xstate_size for xstate size in signal
    context
  x86/xsaves: Rename xstate_size to kernel_xstate_size to explicitly
    distinguish xstate size in kernel from user space
  x86/xsave: Don't add new states in xsave_struct

 arch/x86/include/asm/fpu-internal.h |   7 ++-
 arch/x86/include/asm/processor.h    |  23 +++----
 arch/x86/include/asm/xsave.h        |   1 -
 arch/x86/kernel/i387.c              |  18 +++---
 arch/x86/kernel/process.c           |   2 +-
 arch/x86/kernel/xsave.c             | 120 +++++++++++++++++++++++++++++-------
 6 files changed, 118 insertions(+), 53 deletions(-)

-- 
1.8.1.2

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