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: <3E5A0FA7E9CA944F9D5414FEC6C712205C8C5C7F@ORSMSX106.amr.corp.intel.com>
Date:	Tue, 21 Apr 2015 12:54:04 +0000
From:	"Yu, Fenghua" <fenghua.yu@...el.com>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Ingo Molnar <mingo@...nel.org>,
	"Mallick, Asit K" <asit.k.mallick@...el.com>,
	"Hansen, Dave" <dave.hansen@...el.com>,
	"Williamson, Glenn P" <glenn.p.williamson@...el.com>,
	linux-kernel <linux-kernel@...r.kernel.org>, x86 <x86@...nel.org>
Subject: RE: [PATCH Bugfix 1/4] x86/xsave.c: Fix xstate offsets and sizes
 enumeration

> From: Thomas Gleixner [mailto:tglx@...utronix.de]
> Sent: Tuesday, April 21, 2015 2:17 AM
> On Sat, 18 Apr 2015, Fenghua Yu wrote:
> 
> > From: Fenghua Yu <fenghua.yu@...el.com>
> >
> > When enumerating xstate offsets and sizes from cpuid (eax=0x0d,
> > ecx>=2), it's possible that state m is not implemented while state n
> > (n>m) is implemented. So enumeration shouldn't stop at state m.
> >
> > There is no platform configured like above yet. But this could be a
> > problem in the future.
> 
> So this is for future hardware. Why are you claiming this is a BUGFIX?

I think the current code does not follow xstate offsets and sizes
definition based on SDM. So it is buggy. When platforms have more
xsates, it's becoming more possible to hit the issue because platforms
have more chances to disable some xstates and leave holes in xsave
area. And I do see an internal platform may hit the issue. That's why I
claim this is a BUGFIX.

> 
> This is a regular hardware enablement or are you saying that this is backport
> material?

I would like the patch to be backported to distros or stable kernel because
we may really see the issue in near future if it's not backported.

> 
> Confused.

Thanks.

-Fenghua


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ