linux-kernel - Re: AES-NI data corruption issues

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] [day] [month] [year] [list]

Date:	Thu, 16 Feb 2012 10:45:05 +0100
From:	Mathias Krause <minipli@...glemail.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org,
	Herbert Xu <herbert@...dor.apana.org.au>
Subject: Re: AES-NI data corruption issues

On Wed, Feb 15, 2012 at 5:20 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Wed, Feb 15, 2012 at 12:51 AM, Mathias Krause <minipli@...glemail.com> wrote:
>>
>> Can you please elaborate a little more on the AES-NI issues you're
>> seeing as I cannot find any information about them on
>> LKML/bugzilla/linux-crypto? Are they limited to the 3.3-rc kernels or
>> are they happening on released kernels as well? Are they happening on
>> 32 bit, 64 bit or both?
>
> So far we have reports from just one person, and it's seems limited to
> 32-bit and using the AES instructions from interrupts - by the WiFi
> layer.
>
> We have not figured out what's wrong yet, but it doesn't look like
> it's AES-NI itself: it seems to be some FP state mixup (right now it
> looks like the TS_USEDFPU bit we use to track it gets confused). It is
> probably just triggered by the very unusual case of the mac80211 code
> wanting to use FP state from interrupts.

Maybe it was a bad idea porting that code to 32 bit. Honestly, I
haven't checked if the kernel can save and restore the FP state
(especially the MMX/SSE state) correctly while doing the port. But as
my tests with dm-crypt worked flawlessly I was implying it can.

> There's a few other reports that *may* be the same thing, but they
> also seem to be about wireless, and using WPA with AES. In fact, we
> have no real reason to even consider them related to AES-NI at all,
> other than that commonality.

I'm actively using AES-NI with WPA as well for quite some months now
without any problems. I'm running on a 64 bit kernel, though. So this
problem may be 32 bit only.

> Anyway, AES-NI itself seems to be fine, everything we have so far
> points to the FPU/MMX state handling being very subtly broken.

Lets hope they get fixed soon.

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/