lkml.org 
[lkml]   [2012]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: AES-NI data corruption issues
From
On Wed, Feb 15, 2012 at 5:20 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Feb 15, 2012 at 12:51 AM, Mathias Krause <minipli@googlemail.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


\
 
 \ /
  Last update: 2012-02-16 10:47    [W:0.695 / U:0.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site