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: <49BEFDFB.8070900@zytor.com>
Date:	Mon, 16 Mar 2009 18:33:47 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Andi Kleen <andi@...stfloor.org>
CC:	Jan Beulich <jbeulich@...ell.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	the arch/x86 maintainers <x86@...nel.org>,
	Xen-devel <xen-devel@...ts.xensource.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] [PATCH 10/24] xen: mask XSAVE from cpuid

Andi Kleen wrote:
> "Jan Beulich" <jbeulich@...ell.com> writes:
> 
>>>>> Arjan van de Ven <arjan@...radead.org> 16.03.09 01:09 >>>
>>> Well.. pretty much all new instructions need Xen modifications due to
>>> the need to be emulate to deal with traps/vmexits/etc right? 
>>> So I don't quite see many cpuid bits that would NOT involve some Xen
>>> modification or another ;)
>> No, new (user-mode accessible) instructions represent precisely the kind
>> of extension that do not require hypervisor (or OS) awareness (see SSE2
>> etc, AES, FMA). New registers otoh are examples of where awareness is
>> needed (SSE, AVX), as would be new privileged instructions.
> 
> Whey would another hypothetical FP register extension need Xen support
> once it gets proper XSAVE support? I can't think of a reason why
> (assuming XSAVE support) it would need to know of a new kind of
> FP register or similar. They very likely won't appear in any 
> instructions that need mmio. Or are you worried about the real
> mode emulator?
> 

The point is YOU DON'T KNOW.  In particular, there might be new traps,
there might be new state, there might be new MSRs, there might be new
control bits... anything.  Therefore, you cannot blindly pass the bit
on, even though XSAVE solves one part of the problem.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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