linux-kernel - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 17 Nov 2011 13:36:41 +0100
From:	Mathias Krause <minipli@...glemail.com>
To:	Jan Beulich <JBeulich@...e.com>
Cc:	herbert@...dor.apana.org.au, linux-kernel@...r.kernel.org
Subject: Re: your patch "crypto: sha1 - SSSE3 based SHA1 implementation for
 x86-64" vs xsave

On Thu, Nov 17, 2011 at 11:33 AM, Jan Beulich <JBeulich@...e.com> wrote:
> 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.

Well, it does, at least in my setup, a Core i7-2620M:

  [   44.902613] sha1_ssse3: Using AVX optimized SHA-1 implementation

> 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

That's a valid point. I actually ported the check from the initial
assembler implementation which was written with userland code in mind.
Albeit this test can also be used in kernel code because the kernel
only sets this flag after xsave was enabled in
arch/x86/kernel/xsave.c:xstate_enable_boot_cpu/xstate_enable

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

I don't see where X86_CR4_OSXSAVE would get reset after xsave init.
Can you give me a pointer to that code?

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

When noxsave is given on the kernel command line, X86_FEATURE_XSAVE
will be cleared and xsave_init() won't call xstate_enable(), so not
setting X86_CR4_OSXSAVE. All fine.

Thanks,
Mathias
--
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/