linux-kernel - Re: x86_64: movdqu rarely stores bad data (movdqu works fine). Kernel bug, fried CPU or glibc bug?

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:   Sun, 17 Jun 2018 22:39:41 +0100
From:   Sergei Trofimovich <slyich@...il.com>
To:     libc-alpha@...rceware.org, linux-kernel@...r.kernel.org,
        x86@...nel.org
Cc:     "H.J. Lu" <hjl.tools@...il.com>
Subject: Re: x86_64: movdqu rarely stores bad data (movdqu works fine).
 Kernel bug, fried CPU or glibc bug?

On Sat, 16 Jun 2018 22:22:50 +0100
Sergei Trofimovich <slyich@...il.com> wrote:

> TL;DR: on master string/test-memmove glibc test fails on my machine
> and I don't know why. Other tests work fine.
> ...
> This fails:
>   loop {
>     movdqu [src++],%xmm0
>     movntdq %xmm0,[dst++]
>   }
>   sfence
> This works:
>   loop {
>     movdqu [src++],%xmm0
>     movdqu %xmm0,[dst++]
>   }
>   sfence
> ...
> If there is no obvious problems with glibc's memove() or my small test
> what can I do to rule-out/pin-down hardware or kernel problem?

Found the cause: bad RAM module.

After I've tweaked test to allocate most of available physical RAM
I've got fully reproducible failure.

I unplugged RAM modules one by one and ran the test. That way I've
nailed down to one bad chip. Removing single bad chip restored
string/test-memmove test on this machine \o/

Sorry for the noise!

-- 

  Sergei

Content of type "application/pgp-signature" skipped