Bug#733551: Sanitation of CPU-state when switching from virtual-8086 mode to other task incomplete
Bastian Blank wrote:
> Control: tag -1 moreinfo
>
> On Sun, Dec 29, 2013 at 09:12:35PM +0000, halfdog wrote:
>> When executing code in virtual-8086 mode via vm86 syscall, kernel
>> seems to perform incomplete CPU state sanitation when switching tasks,
>> thus causing OOPSes or complete machine lockup.
>
> You only showed exceptions while running within VirtualBox. Please also
> show some while running on real hardware.
Because I did not care to copy the OOPSes from the initrd via USB to
crypto-disks since most of them were triggered in already well-known
fault location, also primary problem at emms instruction
(math_state_restore+0x3e/0x140 is a much easier target to hit). I'll try
to capture on real hardware when hardware is idle again.
[ 4194.121492] fpu exception: 0000 [#1]
[ 4194.123114] Modules linked in: nfnetlink_log nfnetlink xt_multiport
xt_hashlimit xt_tcpudp ipt_ULOG xt_LOG xt_conntrack iptable_raw
iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat
nf_conntrack iptable_mangle iptable_filter ip_tables x_tables snd_pcm
snd_page_alloc snd_timer snd parport_pc soundcore microcode psmouse
serio_raw pcspkr evdev parport ac battery button i2c_piix4 i2c_core ext4
crc16 mbcache jbd2 sg sr_mod sd_mod cdrom crc_t10dif ata_generic
ata_piix mptspi scsi_transport_spi mptscsih libata mptbase pcnet32 mii
scsi_mod
[ 4194.123114] CPU: 0 PID: 2326 Comm: Virtual86Random Not tainted
3.11-2-486 #1 Debian 3.11.10-1
[ 4194.123114] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
VirtualBox 12/01/2006
[ 4194.123114] task: cf439400 ti: ccfd6000 task.ti: ccfd6000
[ 4194.123114] EIP: 0060:[<c100230e>] EFLAGS: 00010002 CPU: 0
[ 4194.123114] EIP is at math_state_restore+0x3e/0x140
[ 4194.123114] EAX: 8005003b EBX: cf439400 ECX: 0000007b EDX: ffffffff
[ 4194.123114] ESI: 00000000 EDI: c1399bb0 EBP: 00000400 ESP: ccfd7eb4
[ 4194.123114] DS: 007b ES: 007b FS: 0000 GS: 00e0 SS: 0068
[ 4194.123114] CR0: 80050033 CR2: 00000000 CR3: 0da55000 CR4: 00000690
[ 4194.123114] Stack:
[ 4194.123114] ccfd7ed0 c1399bb0 c1399c05 c1023f17 ccfd7ef8 00000000
c1399585 00000000
[ 4194.123114] 0000ffff 00000000 00000000 0000be77 00000400 00000000
00000000 00000000
[ 4194.123114] 00000000 00000000 ffffffff 0000ee89 00001000 00030202
000003f8 00001000
[ 4194.123114] Call Trace:
[ 4194.123114] [<c1399bb0>] ? do_debug+0x160/0x160
[ 4194.123114] [<c1399c05>] ? do_device_not_available+0x55/0x70
[ 4194.123114] [<c1023f17>] ? SYSC_vm86+0x97/0x280
[ 4194.123114] [<c1399585>] ? error_code+0x65/0x70
[ 4194.123114] [<c10243ed>] ? SyS_vm86+0xd/0x10
[ 4194.123114] [<c1398fef>] ? syscall_call+0x7/0xb
[ 4194.123114] Code: 00 89 d8 e8 15 62 00 00 85 c0 0f 85 95 00 00 00 fa
90 8d 74 26 00 e9 50 00 00 00 c7 83 4c 02 00 00 01 00 00 00 89 1d 74 cd
4d c1 <0f> 77 db 83 4c 02 00 00 89 f6 eb 3e b8 ff ff ff ff 8b bb 50 02
[ 4194.123114] EIP: [<c100230e>] math_state_restore+0x3e/0x140 SS:ESP
0068:ccfd7eb4
>> See [1] for reproducers. Vrtual86SwitchToEmmsFault.c locks up
>> reproducible when run in one VirtualBox guest, but fails to do so on
>> real hardware. The random code tool Virtual86RandomCode.c might yield
>> better results on those machines.
>
> So it does _not_ fail on real hardware. Why do you think this is a
> kernel bug then?
The specific test does not kill the idle task on real hardware but
faults in a different way (math_state_restore). Perhaps memory layout is
somehow relevant.
Did you try the random code test? Perhaps the fault is specific to
AMD-processors? You can use 'Virtual86RandomCode < /dev/urandom >
/dev/null', on this hardware it took just some ms to trigger first faults.
--
http://www.halfdog.net/
PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee
Reply to: