linux-kernel - Re: AVX "Sandy Bridge" hardware issue?

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, 12 Jul 2011 17:49:35 -0700
From:	Andi Kleen <andi@...stfloor.org>
To:	MK <mk@...nitivedissonance.ca>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: AVX "Sandy Bridge" hardware issue?

MK <mk@...nitivedissonance.ca> writes:
>
> In which Andreas Schwab points out (rightly or wrongly) that according
> to the /proc/cpuinfo from the slice, the processor actually does not
> support AVX.  However,  the "model name", "Intel(R) Xeon(R) CPU
> E31230", is according to this a Sandy Bridge processor with AVX:

If it's in a VM then the VM may not expose AVX to the guest
(the VMs have to do that explicitely because AVX has additional state). 
If it's not in /proc/cpuinfo on the guest that's likely the case.

However glibc should of course not use AVX in this case.

> Does anyone have any idea why I would get this identical backtrace, and
> a failed reproducer test, on hardware which supposedly supports AVX
> (but not according to the kernel in /proc/cpuinfo)?

If there's a problem then it's likely in the VM. Maybe it leaks
AVX partially through only.

For example I had a similar problem a long time ago on a system
which had inconsistent CPU features for different CPUs. The kernel
will chose the least common denominator, but an application
directly calling CPUID can sometimes see different flags and then
crash when it switches CPUs.

The symptoms would be consistent with that.

I would contact the VM vendor.

-Andi

-- 
ak@...ux.intel.com -- Speaking for myself only
--
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/