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

Message-ID: <31917a94-5752-8333-08ad-f895139e73e8@univention.de>
Date:   Sun, 18 Jun 2017 21:54:21 +0200
From:   Philipp Hahn <hahn@...vention.de>
To:     "Dr. David Alan Gilbert" <linux@...blig.org>
Cc:     Laszlo Ersek <lersek@...hat.com>, 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

Am 18.06.2017 um 20:27 schrieb Dr. David Alan Gilbert:
> * Philipp Hahn (hahn@...vention.de) wrote:
>> Hello,
>>
>> 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
>>
>> 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.
> 
> What host CPU are you using?

Everything is amd64:
> processor       : 3
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 58
> model name      : Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz
> stepping        : 9
> microcode       : 0x19
> cpu MHz         : 2591.015
> cache size      : 3072 KB
> physical id     : 0
> siblings        : 4
> core id         : 1
> cpu cores       : 2
> apicid          : 3
> initial apicid  : 3
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 13
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm epb tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts
> bugs            :
> bogomips        : 3592.75
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 36 bits physical, 48 bits virtual
> power management:

Philipp