linux-kernel - Re: [Qemu-devel] [RFH] qemu-2.6 memory corruption with OVMF and linux-4.9

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]

Message-ID: <d323a0b6-164f-7378-c565-e42128cf56b6@pmhahn.de>
Date:   Tue, 20 Jun 2017 12:08:56 +0200
From:   Philipp Hahn <pmhahn@...ahn.de>
To:     Philipp Hahn <hahn@...vention.de>, Laszlo Ersek <lersek@...hat.com>
Cc:     qemu-devel@...gnu.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Peter Jones <pjones@...hat.com>, linux-fbdev@...r.kernel.org
Subject: Re: [Qemu-devel] [RFH] qemu-2.6 memory corruption with OVMF and
 linux-4.9

Hello,

Am 18.06.2017 um 20:22 schrieb Philipp Hahn:
> Am 17.06.2017 um 18:51 schrieb Laszlo Ersek:
>> (I also recommend using the "vbindiff" tool for such problems, it is
>> great for picking out patterns.)
>>
>>           ** ** ** ** ** ** ** **   8  9 ** ** ** 13 14 15
>>           -- -- -- -- -- -- -- --  -- -- -- -- -- -- -- --
>> 00000000  01 e8 00 00 00 00 00 00  8c 5e 00 00 00 10 ff f1
>> 00000010  5b 78 8a 3e 00 00 00 00  00 00 00 00 00 00 00 00
>> 00000020  8c 77 00 00 00 12 00 02  18 f0 00 00 00 00 00 00
>> 00000030  00 1e 00 00 00 00 00 00  8c 8c 00 00 00 12 00 02
>> 00000040  07 70 00 00 00 00 00 00  00 14 00 00 00 00 00 00
>> 00000050  8c 9c 00 00 00 12 00 02  22 00 00 00 00 00 00 00
>> 00000060  00 40 00 00 00 00 00 00  8c ac 00 00 00 10 ff f1
>>
>> 00000000  01 e8 00 00 00 00 00 00  00 3c 00 00 00 17 00 00
>> 00000010  5b 78 8a 3e 00 00 00 00  00 3c 00 00 00 07 00 00
>> 00000020  8c 77 00 00 00 12 00 02  00 3c 00 00 00 07 00 00
>> 00000030  00 1e 00 00 00 00 00 00  00 3c 00 00 00 17 00 00
>> 00000040  07 70 00 00 00 00 00 00  00 3c 00 00 00 07 00 00
>> 00000050  8c 9c 00 00 00 12 00 02  00 3c 00 00 00 07 00 00
>> 00000060  00 40 00 00 00 00 00 00  00 3c 00 00 00 17 00 00
>>           -- -- -- -- -- -- -- --  -- -- -- -- -- -- -- --
>>           ** ** ** ** ** ** ** **   8  9 ** ** ** 13 14 15
>>
>> The columns that I marked with "**" are identical between "good" and
>> "bad". (These are columns 0-7, 10-12.)
>>
>> Column 8 is overwritten by zeros (every 16th byte).
>>
>> Column 9 is overwritten by 0x3c (every 16th byte).
>>
>> Column 13 is super interesting. The most significant nibble in that
>> column is not disturbed. And, in the least significant nibble, the least
>> significant three bits are turned on. Basically, the corruption could be
>> described, for this column (i.e., every 16th byte), as
>>
>>   bad = good | 0x7
>>
>> Column 14 is overwritten by zeros (every 16th byte).
>>
>> Column 15 is overwritten by zeros (every 16th byte).
>>
>> My take is that your host machine has faulty RAM. Please run memtest86+
>> or something similar.
> 
> I will do so, but for me very unlikely:
> - it never happens with BIOS, only with OVMF
> - for each test I start q new QEMU process, which should use a different
> memory region
> - it repeatedly hits e1000 or libata.ko

Okay: memtest+-5.01 run for 8h and did not find any errors in those 3
passes.

> After updating from OVMF to 0~20161202.7bbe0b3e-1 from
> (0~20160813.de74668f-2 it has not yet happened again.

Anyway, thank you for your help.

Philipp