linux-kernel - your patch "crypto: sha1 - SSSE3 based SHA1 implementation for x86-64" vs xsave

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]

Message-Id: <4EC4F0FD0200007800061840@nat28.tlf.novell.com>
Date:	Thu, 17 Nov 2011 10:33:17 +0000
From:	"Jan Beulich" <JBeulich@...e.com>
To:	<minipli@...glemail.com>
Cc:	<herbert@...dor.apana.org.au>, <linux-kernel@...r.kernel.org>
Subject: your patch "crypto: sha1 - SSSE3 based SHA1 implementation for
 x86-64" vs xsave

Mathias,

in avx_usable() you use cpu_has_osxsave to determine whether AVX can
actually be used, but I can't see how that conditional would ever evaluate
to true. Checking CPUID.OSXSAVE is actually a user land requirement,
whereas in the kernel you should really look at kernel internal variables
to determine whether xsave was enabled (or, if you really want to stay
with using cpu_has_osxsave you'd have to force re-execution of
get_cpu_cap() after xsave got enabled on individual CPUs), namely
mmu_cr4_features having X86_CR4_OSXSAVE set.

Additionally, under a hypervisor, CPUID.OSXSAVE may be set (due to
the hypervisor having enabled xsave), while the kernel may be running
with xsave disabled (e.g. due to a command line option saying so).

Thanks, Jan

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