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

Message-ID: <CA+55aFxWKns=BFo=bw-DDRLwTYjznGbAT+PA5aB-mGTSDieWxQ@mail.gmail.com>
Date:	Wed, 15 Feb 2012 08:20:42 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Mathias Krause <minipli@...glemail.com>
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 12:51 AM, Mathias Krause <minipli@...glemail.com> wrote:
>
>    So this explicitly verifies that we will not touch the TS_USEDFPU bit,
>    and adds a few related sanity-checks.  Because it seems that somehow
>    AES-NI is corrupting user FP state.  The cause is not clear, and this
>    patch doesn't fix it, but while debugging it I really wanted the code to
>    be more obviously correct and robust.
>
> 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.

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.

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

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