Message-ID: <5d090b82-dae7-ac67-a032-92c2e776b70f@univention.de>
Date:   Fri, 16 Jun 2017 19:03:15 +0200
From:   Philipp Hahn <hahn@...vention.de>
To:     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: [RFH] qemu-2.6 memory corruption with OVMF and linux-4.9

Hello,

I tried to get QEMU running with UEFI and SecureBoot. It sometimes
works, but sometimes I get memory corruption:
- the Debian installer sometimes fails to load the "libata.ko" or
"e1000.ko" modules.
- it it not always the same module
- my guest kernel uses KASLR, which might explain different modules
getting corrupted
- the file size is the same
- md5sums differs
- modules are all loaded from InitRamFS.
- depmod detects a cyclic dependency for "libata" on itelf:
> depmod: ERROR: Cycle detected: libata -> libata

Comparing the corrupted (left) with the supposed (right) driver shows
the following pattern:
> /tmp/uefi.bin [+]                                   15038,1      Alles /tmp/uefi.ko [+]                                    15038,1      Alles
>   003ac00: e801 0000 0000 0000 3c00 0000 1700 0000  ........<.......  |  003ac00: e801 0000 0000 0000 5e8c 0000 1000 f1ff  ........^.......  
>   003ac10: 785b 3e8a 0000 0000 3c00 0000 0700 0000  x[>.....<.......  |  003ac10: 785b 3e8a 0000 0000 0000 0000 0000 0000  x[>.............  
>   003ac20: 778c 0000 1200 0200 3c00 0000 0700 0000  w.......<.......  |  003ac20: 778c 0000 1200 0200 f018 0000 0000 0000  w...............  
>   003ac30: 1e00 0000 0000 0000 3c00 0000 1700 0000  ........<.......  |  003ac30: 1e00 0000 0000 0000 8c8c 0000 1200 0200  ................  
>   003ac40: 7007 0000 0000 0000 3c00 0000 0700 0000  p.......<.......  |  003ac40: 7007 0000 0000 0000 1400 0000 0000 0000  p...............  
>   003ac50: 9c8c 0000 1200 0200 3c00 0000 0700 0000  ........<.......  |  003ac50: 9c8c 0000 1200 0200 0022 0000 0000 0000  ........."......  
>   003ac60: 4000 0000 0000 0000 3c00 0000 1700 0000  @.......<.......  |  003ac60: 4000 0000 0000 0000 ac8c 0000 1000 f1ff  @...............  

That's the only difference in the 433702 byte sized file. (libata.ko)

I suspect this to be frame-buffer related, as the EFI frame-buffer is
also broken: see attached screen-shot
> # dmesg
> [    0.980927] efifb: probing for efifb
> [    0.981656] efifb: framebuffer at 0x80000000, using 1876k, total 1875k
> [    0.983030] efifb: mode is 800x600x32, linelength=3200, pages=1
> [    0.984293] efifb: scrolling: redraw
> [    0.985128] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
> [    0.988296] Console: switching to colour frame buffer device 100x37
> [    0.990700] fb0: EFI VGA frame buffer device

My host system is a Debian-Jessie system with newer QEMU components:
> $ dpkg-query -W qemu-system-x86 ovmf linux-image-4.9\*
> linux-image-4.9.0-0.bpo.3-amd64 4.9.25-1~bpo8+1
> ovmf    0~20160813.de74668f-2
> qemu-system-x86 1:2.6+dfsg-3.1~bpo8+1

My guest uses linux-4.9.13 self-compiled:
> CONFIG_RANDOMIZE_BASE=y
> CONFIG_RANDOMIZE_MEMORY=y
> CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING=0xa
> CONFIG_FB_EFI=y
> CONFIG_FRAMEBUFFER_CONSOLE=y
> CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
> CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y

Bootloder is GRUB2, which initialized the frame-buffer to 800x600

QEMU is launched through libvirt:
> qemu-system-x86_64 -enable-kvm -name uefi -S -machine pc-i440fx-2.1,accel=kvm,usb=off -drive file=/usr/share/OVMF/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/var/lib/libvirt/qemu/nvram/uefi_VARS.fd,if=pflash,format=raw,unit=1 -m 2048 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 1d33ad46-5325-4bf0-b87f-e897b8b66946 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/home/phahn/.config/libvirt/qemu/lib/uefi.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device lsi,id=scsi0,bus=pci.0,addr=0x6 -device ahci,id=ahci0,bus=pci.0,addr=0x7 -drive file=/home/libvirt/ucs_4.2-0-latest-amd64.iso,format=raw,if=none,media=cdrom,id=drive-sata0-0-0,readonly=on -device ide-cd,bus=ahci0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 -drive file=/home/libvirt/UEFI.qcow2,format=qcow2,if=none,id=drive-sata0-0-1,cache=unsafe,discard=unmap -device ide-hd,bus=ahci0.1,drive=drive-sata0-0-1,id=sata0-0-1,bootindex=2 -netdev tap,fd=23,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:31:e6:b4,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev file,id=charserial1,path=/tmp/uefi.log -device isa-serial,chardev=charserial1,id=serial1 -vnc 127.0.0.1:0 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -global isa-debugcon.iobase=0x402 -debugcon file:/tmp/ovmf.log -msg timestamp=on


Has someone seen a similar issue or is this even a known issue?


I will try a newer version of QEMU and OVMF next.

Thank you in advance for your input.

Philipp
-- 
Philipp Hahn
Open Source Software Engineer

Univention GmbH
be open.
Mary-Somerville-Str. 1
D-28359 Bremen
Tel.: +49 421 22232-0
Fax : +49 421 22232-99
hahn@...vention.de

http://www.univention.de/
Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876

Download attachment "Bildschirmfoto86.png" of type "image/png" (64623 bytes)

Powered by blists - more mailing lists