* Sanitize CPU-state when switching from virtual-8086 mode to other task @ 2013-12-28 22:02 halfdog 2013-12-29 2:37 ` H. Peter Anvin 0 siblings, 1 reply; 24+ messages in thread From: halfdog @ 2013-12-28 22:02 UTC (permalink / raw) To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin; +Cc: x86, linux-kernel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It seems that missing CPU-state sanitation during task switching triggers kernel-panic. This might be related to unhandled FPU-errors. See [1] for POC and serial console log of OOPs. Due to missing real 32-bit x86-hardware it is not clear, if this issue might be related to subtle differences in virtual-8086 mode handling when inside a virtualbox guest. hd [1] http://www.halfdog.net/Security/2013/Vm86SyscallTaskSwitchKernelPanic/ [ 348.270712] fpu exception: 0000 [#1] [ 348.270763] 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 [ 348.270763] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 3.11-2-486 #1 Debian 3.11.10-1 [ 348.270763] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 348.270763] task: cf835400 ti: cf930000 task.ti: cf84a000 [ 348.270763] EIP: 0060:[<c10013e0>] EFLAGS: 00010002 CPU: 0 [ 348.270763] EIP is at __switch_to+0x190/0x300 [ 348.270763] EAX: cd2eec00 EBX: cd2eec00 ECX: 00000000 EDX: 00000000 [ 348.270763] ESI: cf835400 EDI: 00000001 EBP: cd2eedf8 ESP: cf931a40 [ 348.270763] DS: 007b ES: 007b FS: 0000 GS: 00e0 SS: 0068 [ 348.270763] CR0: 80050033 CR2: b76997e0 CR3: 0d11a000 CR4: 00000690 [ 348.270763] Stack: [ 348.270763] 4a6ef7ab ccee9c80 ccee9900 cf835400 c13978cf cd2eec00 00200082 c15de480 [ 348.270763] 00000018 67bf6d70 cf930000 cd2eec00 1625d3df 00000051 cd2eec2c c1056e15 [ 348.270763] 00200086 0000000a cf931a90 c1006cc8 00393f1e 00000000 5d3e5d0f 00000040 [ 348.270763] Call Trace: [ 348.270763] [<c13978cf>] ? __schedule+0x1ef/0x510 [ 348.270763] [<c1056e15>] ? update_curr+0x95/0x140 [ 348.270763] [<c1006cc8>] ? sched_clock+0x8/0x10 [ 348.270763] [<c13973d5>] ? schedule_hrtimeout_range_clock+0x165/0x180 [ 348.270763] [<c1044e9f>] ? __flush_work+0xbf/0x100 [ 348.270763] [<d0a4fa59>] ? nf_nat_get_offset+0x39/0x60 [nf_nat] [ 348.270763] [<d0a68df7>] ? tcp_packet+0x637/0xf40 [nf_conntrack] [ 348.270763] [<c124932c>] ? tty_write_room+0xc/0x20 [ 348.270763] [<c1246fb9>] ? n_tty_poll+0x189/0x1a0 [ 348.270763] [<c13973ff>] ? schedule_hrtimeout_range+0xf/0x20 [ 348.270763] [<c11093a0>] ? poll_schedule_timeout+0x20/0x40 [ 348.270763] [<c1109c77>] ? do_select+0x537/0x5f0 [ 348.270763] [<c11094d0>] ? poll_select_copy_remaining+0x110/0x110 [ 348.270763] [<c11094d0>] ? poll_select_copy_remaining+0x110/0x110 [ 348.270763] [<c11094d0>] ? poll_select_copy_remaining+0x110/0x110 [ 348.270763] [<c11094d0>] ? poll_select_copy_remaining+0x110/0x110 [ 348.270763] [<c12f688d>] ? nf_iterate+0x7d/0x90 [ 348.270763] [<c1067e6c>] ? __getnstimeofday+0x2c/0x110 [ 348.270763] [<c133f7f2>] ? bictcp_cong_avoid+0x12/0x4a0 [ 348.270763] [<c1067f55>] ? getnstimeofday+0x5/0x20 [ 348.270763] [<c131116b>] ? tcp_ack+0x82b/0xdc0 [ 348.270763] [<c10353a0>] ? local_bh_enable+0x70/0x80 [ 348.270763] [<c1300301>] ? ip_finish_output+0x151/0x350 [ 348.270763] [<c10c612a>] ? put_compound_page+0xa/0xe0 [ 348.270763] [<c1311b07>] ? tcp_rcv_established+0xf7/0x7a0 [ 348.270763] [<c12c1edc>] ? sk_reset_timer+0xc/0x20 [ 348.270763] [<c131a94e>] ? tcp_v4_do_rcv+0x15e/0x3b0 [ 348.270763] [<c12c3558>] ? release_sock+0x88/0xf0 [ 348.270763] [<c13088d7>] ? tcp_sendmsg+0x177/0xc60 [ 348.270763] [<c1056e15>] ? update_curr+0x95/0x140 [ 348.270763] [<c1109e5c>] ? core_sys_select+0x12c/0x220 [ 348.270763] [<c12beee1>] ? sock_aio_write+0xe1/0x110 [ 348.270763] [<c10f9cda>] ? do_sync_write+0x6a/0xa0 [ 348.270763] [<c112b673>] ? fsnotify+0x203/0x2f0 [ 348.270763] [<c1109fdf>] ? SyS_select+0x8f/0xc0 [ 348.270763] [<c100aca2>] ? syscall_trace_leave+0xa2/0xb0 [ 348.270763] [<c1398fef>] ? syscall_call+0x7/0xb [ 348.270763] Code: e9 1d ff ff ff 8d b6 00 00 00 00 b8 7d 00 00 00 e8 36 b8 00 00 84 c0 0f 85 e1 fe ff ff 0f 06 8d 74 26 00 e9 d6 fe ff ff 8d 76 00 <0f> 77 db 83 4c 02 00 00 89 f6 8d b6 00 00 00 00 eb 66 b8 ff ff [ 348.270763] EIP: [<c10013e0>] __switch_to+0x190/0x300 SS:ESP 0068:cf931a40 [ 348.270763] ---[ end trace c3836805b501f815 ]--- [ 348.274764] ------------[ cut here ]------------ [ 348.278424] kernel BUG at /build/linux-tAcKXn/linux-3.11.10/kernel/exit.c:870! [ 348.278764] invalid opcode: 0000 [#2] [ 348.278764] 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 [ 348.278764] CPU: 0 PID: 2220 Comm: sshd Tainted: G D 3.11-2-486 #1 Debian 3.11.10-1 [ 348.278764] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 348.278764] task: cd2eec00 ti: cf930000 task.ti: cf930000 [ 348.278764] EIP: 0060:[<c103348a>] EFLAGS: 00010282 CPU: 0 [ 348.278764] EIP is at do_exit+0x44a/0x830 [ 348.278764] EAX: 00000080 EBX: cf835400 ECX: 00000000 EDX: cd2eec00 [ 348.278764] ESI: 00000001 EDI: 00000001 EBP: cf835c00 ESP: cf93190c [ 348.278764] DS: 007b ES: 007b FS: 0000 GS: 00e0 SS: 0068 [ 348.278764] CR0: 80050033 CR2: b74faf38 CR3: 0d11a000 CR4: 00000690 [ 348.278764] Stack: [ 348.278764] 0000000b cf931a04 00000010 c1393e1c cf835510 cf8353f8 cf835510 00000001 [ 348.278764] cf835558 cf931930 cf931930 00000046 0000000b cf931a04 00000010 c1399cf1 [ 348.278764] cf931a04 cf931a04 cf835400 c1446e22 c10029be 00000000 00000010 00000008 [ 348.278764] Call Trace: [ 348.278764] [<c1393e1c>] ? printk+0x37/0x3b [ 348.278764] [<c1399cf1>] ? oops_end+0x81/0xc0 [ 348.278764] [<c10029be>] ? math_error+0x14e/0x2d0 [ 348.278764] [<c1056e15>] ? update_curr+0x95/0x140 [ 348.278764] [<c1056921>] ? sched_slice.isra.35+0x41/0x80 [ 348.278764] [<c1055a8a>] ? update_cpu_load_active+0x1a/0x80 [ 348.278764] [<c1056e15>] ? update_curr+0x95/0x140 [ 348.278764] [<c1002b40>] ? math_error+0x2d0/0x2d0 [ 348.278764] [<c1399585>] ? error_code+0x65/0x70 [ 348.278764] [<c10013e0>] ? __switch_to+0x190/0x300 [ 348.278764] [<c13978cf>] ? __schedule+0x1ef/0x510 [ 348.278764] [<c1056e15>] ? update_curr+0x95/0x140 [ 348.278764] [<c1006cc8>] ? sched_clock+0x8/0x10 [ 348.278764] [<c13973d5>] ? schedule_hrtimeout_range_clock+0x165/0x180 [ 348.278764] [<c1044e9f>] ? __flush_work+0xbf/0x100 [ 348.278764] [<d0a4fa59>] ? nf_nat_get_offset+0x39/0x60 [nf_nat] [ 348.278764] [<d0a68df7>] ? tcp_packet+0x637/0xf40 [nf_conntrack] [ 348.278764] [<c124932c>] ? tty_write_room+0xc/0x20 [ 348.278764] [<c1246fb9>] ? n_tty_poll+0x189/0x1a0 [ 348.278764] [<c13973ff>] ? schedule_hrtimeout_range+0xf/0x20 [ 348.278764] [<c11093a0>] ? poll_schedule_timeout+0x20/0x40 [ 348.278764] [<c1109c77>] ? do_select+0x537/0x5f0 [ 348.278764] [<c11094d0>] ? poll_select_copy_remaining+0x110/0x110 [ 348.278764] [<c11094d0>] ? poll_select_copy_remaining+0x110/0x110 [ 348.278764] [<c11094d0>] ? poll_select_copy_remaining+0x110/0x110 [ 348.278764] [<c11094d0>] ? poll_select_copy_remaining+0x110/0x110 [ 348.278764] [<c12f688d>] ? nf_iterate+0x7d/0x90 [ 348.278764] [<c1067e6c>] ? __getnstimeofday+0x2c/0x110 [ 348.278764] [<c133f7f2>] ? bictcp_cong_avoid+0x12/0x4a0 [ 348.278764] [<c1067f55>] ? getnstimeofday+0x5/0x20 [ 348.278764] [<c131116b>] ? tcp_ack+0x82b/0xdc0 [ 348.278764] [<c10353a0>] ? local_bh_enable+0x70/0x80 [ 348.278764] [<c1300301>] ? ip_finish_output+0x151/0x350 [ 348.278764] [<c10c612a>] ? put_compound_page+0xa/0xe0 [ 348.278764] [<c1311b07>] ? tcp_rcv_established+0xf7/0x7a0 [ 348.278764] [<c12c1edc>] ? sk_reset_timer+0xc/0x20 [ 348.278764] [<c131a94e>] ? tcp_v4_do_rcv+0x15e/0x3b0 [ 348.278764] [<c12c3558>] ? release_sock+0x88/0xf0 [ 348.278764] [<c13088d7>] ? tcp_sendmsg+0x177/0xc60 [ 348.278764] [<c1056e15>] ? update_curr+0x95/0x140 [ 348.278764] [<c1109e5c>] ? core_sys_select+0x12c/0x220 [ 348.278764] [<c12beee1>] ? sock_aio_write+0xe1/0x110 [ 348.278764] [<c10f9cda>] ? do_sync_write+0x6a/0xa0 [ 348.278764] [<c112b673>] ? fsnotify+0x203/0x2f0 [ 348.278764] [<c1109fdf>] ? SyS_select+0x8f/0xc0 [ 348.278764] [<c100aca2>] ? syscall_trace_leave+0xa2/0xb0 [ 348.278764] [<c1398fef>] ? syscall_call+0x7/0xb [ 348.278764] Code: 74 05 e8 9a 2d 09 00 8b 83 c4 03 00 00 85 c0 74 06 01 05 60 d8 4e c1 f3 90 81 4b 0c 00 80 00 00 c7 03 40 00 00 00 e8 66 47 36 00 <0f> 0b 8d 74 26 00 8b 46 10 85 c0 0f 85 67 02 00 00 89 ae 0c 01 [ 348.278764] EIP: [<c103348a>] do_exit+0x44a/0x830 SS:ESP 0068:cf93190c [ 348.278776] ---[ end trace c3836805b501f816 ]--- [ 348.285890] type=1106 audit(1388235169.398:64338): pid=2218 uid=0 auid=1000 ses=2 [ 348.285890] msg='op=PAM:session_close acct="test" exe="/usr/sbin/sshd" hostname=10.255.255.1 addr=10.255.255.1 terminal=ssh res=success' [ 348.287096] type=1104 audit(1388235169.402:64339): pid=2218 uid=0 auid=1000 ses=2 [ 348.287096] msg='op=PAM:setcred acct="test" exe="/usr/sbin/sshd" hostname=10.255.255.1 addr=10.255.255.1 terminal=ssh res=success' [ 348.766895] fpu exception: 0000 [#3] [ 348.770794] 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 [ 348.770794] CPU: 0 PID: 0 Comm: swapper Tainted: G D 3.11-2-486 #1 Debian 3.11.10-1 [ 348.770794] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 348.770794] task: c14d84e0 ti: cdd84000 task.ti: c14cc000 [ 348.770794] EIP: 0060:[<c10013e0>] EFLAGS: 00210002 CPU: 0 [ 348.770794] EIP is at __switch_to+0x190/0x300 [ 348.770794] EAX: cf5ec000 EBX: cf5ec000 ECX: 00000000 EDX: 00000000 [ 348.770794] ESI: c14d84e0 EDI: 00000001 EBP: cf5ec1f8 ESP: cdd85ad8 [ 348.770794] DS: 007b ES: 007b FS: 0000 GS: 00e0 SS: 0068 [ 348.770794] CR0: 80050033 CR2: b7662000 CR3: 0cdb3000 CR4: 00000690 [ 348.770794] Stack: [ 348.770794] 37df9a44 ccf3d040 ccf3dac0 c14d84e0 c13978cf cf5ec000 00200082 00000000 [ 348.770794] 00000000 00000000 cdd84000 cf5ec000 00000000 ccf11ef0 c14e6e98 c11c4d70 [ 348.770794] 65747300 cdd85b7c c14e6e8c c104d0ca 65747300 cdd85b7c c14e6e8c 00200292 [ 348.770794] Call Trace: [ 348.770794] [<c13978cf>] ? __schedule+0x1ef/0x510 [ 348.770794] [<c11c4d70>] ? timerqueue_add+0x50/0xb0 [ 348.770794] [<c104d0ca>] ? enqueue_hrtimer+0x1a/0x60 [ 348.770794] [<c1397332>] ? schedule_hrtimeout_range_clock+0xc2/0x180 [ 348.770794] [<c104cdc0>] ? hrtimer_get_res+0x30/0x30 [ 348.770794] [<c139731d>] ? schedule_hrtimeout_range_clock+0xad/0x180 [ 348.770794] [<c13973ff>] ? schedule_hrtimeout_range+0xf/0x20 [ 348.770794] [<c11093a0>] ? poll_schedule_timeout+0x20/0x40 [ 348.770794] [<c110a671>] ? do_sys_poll+0x3f1/0x490 [ 348.770794] [<c12d33c8>] ? dev_queue_xmit+0x1f8/0x3b0 [ 348.770794] [<c10353a0>] ? local_bh_enable+0x70/0x80 [ 348.770794] [<c1300301>] ? ip_finish_output+0x151/0x350 [ 348.770794] [<c13005c8>] ? ip_local_out+0x18/0x20 [ 348.770794] [<c13017cb>] ? ip_send_skb+0xb/0x50 [ 348.770794] [<c132376b>] ? udp_send_skb+0x27b/0x340 [ 348.770794] [<c1323af8>] ? udp_sendmsg+0x268/0x820 [ 348.770794] [<c12ff070>] ? ip_copy_metadata+0x140/0x140 [ 348.770794] [<c11094d0>] ? poll_select_copy_remaining+0x110/0x110 [ 348.770794] [<c11094d0>] ? poll_select_copy_remaining+0x110/0x110 [ 348.770794] [<c11c59f8>] ? put_dec.part.1+0xb8/0x100 [ 348.770794] [<c11c5dcf>] ? number.isra.2+0x38f/0x3a0 [ 348.770794] [<c11c76d9>] ? vsnprintf+0x179/0x420 [ 348.770794] [<c10bbc60>] ? find_get_page+0x10/0x50 [ 348.770794] [<c10bc5af>] ? find_lock_page+0x1f/0x60 [ 348.770794] [<c10ce33d>] ? shmem_getpage_gfp+0x7d/0x680 [ 348.770794] [<c11c5448>] ? format_decode+0x308/0x370 [ 348.770794] [<c11c770b>] ? vsnprintf+0x1ab/0x420 [ 348.770794] [<c10cf09f>] ? shmem_fault+0x3f/0x90 [ 348.770794] [<c10d8059>] ? __do_fault+0x329/0x450 [ 348.770794] [<c1396c18>] ? mutex_lock+0x8/0x15 [ 348.770794] [<c1100f35>] ? pipe_read+0x205/0x470 [ 348.770794] [<c10f9c3a>] ? do_sync_read+0x6a/0xa0 [ 348.770794] [<c1068117>] ? ktime_get_ts+0x37/0xf0 [ 348.770794] [<c1109718>] ? poll_select_set_timeout+0x58/0x80 [ 348.770794] [<c110a7ad>] ? SyS_poll+0x4d/0xb0 [ 348.770794] [<c1398fef>] ? syscall_call+0x7/0xb [ 348.770794] Code: e9 1d ff ff ff 8d b6 00 00 00 00 b8 7d 00 00 00 e8 36 b8 00 00 84 c0 0f 85 e1 fe ff ff 0f 06 8d 74 26 00 e9 d6 fe ff ff 8d 76 00 <0f> 77 db 83 4c 02 00 00 89 f6 8d b6 00 00 00 00 eb 66 b8 ff ff [ 348.770794] EIP: [<c10013e0>] __switch_to+0x190/0x300 SS:ESP 0068:cdd85ad8 [ 348.770794] ---[ end trace c3836805b501f817 ]--- [ 348.770794] Kernel panic - not syncing: Attempted to kill the idle task! - -- http://www.halfdog.net/ PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlK/Sl0ACgkQxFmThv7tq+6hcwCfSwoLsuqvl62oKVsbwUun2fi4 67sAn3UXxmyW8oEbMSuOu2KX7r/D4CMe =YIVj -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Sanitize CPU-state when switching from virtual-8086 mode to other task 2013-12-28 22:02 Sanitize CPU-state when switching from virtual-8086 mode to other task halfdog @ 2013-12-29 2:37 ` H. Peter Anvin 2013-12-29 20:44 ` halfdog 0 siblings, 1 reply; 24+ messages in thread From: H. Peter Anvin @ 2013-12-29 2:37 UTC (permalink / raw) To: halfdog, Thomas Gleixner, Ingo Molnar; +Cc: x86, linux-kernel On 12/28/2013 02:02 PM, halfdog wrote: > It seems that missing CPU-state sanitation during task switching > triggers kernel-panic. This might be related to unhandled > FPU-errors. See [1] for POC and serial console log of OOPs. Due to > missing real 32-bit x86-hardware it is not clear, if this issue > might be related to subtle differences in virtual-8086 mode > handling when inside a virtualbox guest. > This oops happens inside the guest? Either way, I would be *very* skeptical of Virtualbox in this case. You can run a 32-bit kernel on 64-bit hardware, you know... -hpa ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Sanitize CPU-state when switching from virtual-8086 mode to other task 2013-12-29 2:37 ` H. Peter Anvin @ 2013-12-29 20:44 ` halfdog 2013-12-30 1:18 ` H. Peter Anvin 0 siblings, 1 reply; 24+ messages in thread From: halfdog @ 2013-12-29 20:44 UTC (permalink / raw) To: H. Peter Anvin, Thomas Gleixner, Ingo Molnar; +Cc: x86, linux-kernel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 H. Peter Anvin wrote: > On 12/28/2013 02:02 PM, halfdog wrote: >> It seems that missing CPU-state sanitation during task switching >> triggers kernel-panic. This might be related to unhandled >> FPU-errors. See [1] for POC and serial console log of OOPs. Due >> to missing real 32-bit x86-hardware it is not clear, if this >> issue might be related to subtle differences in virtual-8086 >> mode handling when inside a virtualbox guest. >> > > This oops happens inside the guest? Either way, I would be *very* > skeptical of Virtualbox in this case. > > You can run a 32-bit kernel on 64-bit hardware, you know... I know, but hardware was occupied with long-running simulation. With the initial POC, there might be a timing issue involved, with different process layout, exception does not occur in swith_to but sometimes on other locations. I created a new random-code testcase [1] , which works around that problem. When booted a Debian initrd and tried id, OOPSes are fired like wild but at least system does not lock up immediately. hd [1] http://www.halfdog.net/Security/2013/Vm86SyscallTaskSwitchKernelPanic/Virtual86RandomCode.c - -- http://www.halfdog.net/ PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlLAiZEACgkQxFmThv7tq+5dsgCeIqOicLB17PuV7C6AzfZIY9J9 I0UAnA7YftR+4Jz2d5jP6YbpmBBtNOAz =9MJY -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Sanitize CPU-state when switching from virtual-8086 mode to other task 2013-12-29 20:44 ` halfdog @ 2013-12-30 1:18 ` H. Peter Anvin 2013-12-30 15:52 ` halfdog 0 siblings, 1 reply; 24+ messages in thread From: H. Peter Anvin @ 2013-12-30 1:18 UTC (permalink / raw) To: halfdog, Thomas Gleixner, Ingo Molnar; +Cc: x86, linux-kernel On 12/29/2013 12:44 PM, halfdog wrote: > H. Peter Anvin wrote: >> On 12/28/2013 02:02 PM, halfdog wrote: >>> It seems that missing CPU-state sanitation during task >>> switching triggers kernel-panic. This might be related to >>> unhandled FPU-errors. See [1] for POC and serial console log >>> of OOPs. Due to missing real 32-bit x86-hardware it is not >>> clear, if this issue might be related to subtle differences in >>> virtual-8086 mode handling when inside a virtualbox guest. >>> > >> This oops happens inside the guest? Either way, I would be >> *very* skeptical of Virtualbox in this case. > >> You can run a 32-bit kernel on 64-bit hardware, you know... > > I know, but hardware was occupied with long-running simulation. > > With the initial POC, there might be a timing issue involved, with > different process layout, exception does not occur in swith_to but > sometimes on other locations. > > I created a new random-code testcase [1] , which works around that > problem. When booted a Debian initrd and tried id, OOPSes are > fired like wild but at least system does not lock up immediately. > Still in VirtualBox? -hpa ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Sanitize CPU-state when switching from virtual-8086 mode to other task 2013-12-30 1:18 ` H. Peter Anvin @ 2013-12-30 15:52 ` halfdog 2013-12-31 18:42 ` H. Peter Anvin 0 siblings, 1 reply; 24+ messages in thread From: halfdog @ 2013-12-30 15:52 UTC (permalink / raw) To: H. Peter Anvin, Thomas Gleixner, Ingo Molnar; +Cc: x86, linux-kernel H. Peter Anvin wrote: > On 12/29/2013 12:44 PM, halfdog wrote: >> H. Peter Anvin wrote: >>> On 12/28/2013 02:02 PM, halfdog wrote: >>>> It seems that missing CPU-state sanitation during task >>>> switching triggers kernel-panic. This might be related to >>>> unhandled FPU-errors. See [1] for POC and serial console log >>>> of OOPs. Due to missing real 32-bit x86-hardware it is not >>>> clear, if this issue might be related to subtle differences in >>>> virtual-8086 mode handling when inside a virtualbox guest. >>>> >> >>> This oops happens inside the guest? Either way, I would be >>> *very* skeptical of Virtualbox in this case. >> >>> You can run a 32-bit kernel on 64-bit hardware, you know... >> >> I know, but hardware was occupied with long-running simulation. >> >> With the initial POC, there might be a timing issue involved, with >> different process layout, exception does not occur in swith_to but >> sometimes on other locations. >> >> I created a new random-code testcase [1] , which works around that >> problem. When booted a Debian initrd and tried id, OOPSes are >> fired like wild but at least system does not lock up immediately. >> > > Still in VirtualBox? Yes, again: after comparing the results from initrd on real hardware with Vbox, I'm getting to understand the timing problem involved and why timing in VBox is different: The test program usually OOPSes when touching FPU multiple times, otherwise, when terminated before second FPU-interacation, it OOPSes on next invocation, stumbling over invalid CPU state from prior invocation. With improved code, I can rather reliably bring CPU into that state, so that next process invoked and touching FPU/MMX-state is OOPSed. Currently searching SUID-binaries and running UID=0 daemons, that might show interesting reaction on that event, but only on DOS level yet, e.g. after running V2 test program once and then connecting via SSH, this currently kills the ssh daemon nicely. It seems that machine lockup occurs when e.g. switch to idle task happens at exactly the right moment, which I currently cannot trigger on real hardware, but still working on that. -- http://www.halfdog.net/ PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Sanitize CPU-state when switching from virtual-8086 mode to other task 2013-12-30 15:52 ` halfdog @ 2013-12-31 18:42 ` H. Peter Anvin 2013-12-31 19:21 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 24+ messages in thread From: H. Peter Anvin @ 2013-12-31 18:42 UTC (permalink / raw) To: halfdog, Thomas Gleixner, Ingo Molnar; +Cc: x86, linux-kernel On 12/30/2013 07:52 AM, halfdog wrote: >> >> Still in VirtualBox? > > Yes, again: after comparing the results from initrd on real hardware > with Vbox, I'm getting to understand the timing problem involved and why > timing in VBox is different: The test program usually OOPSes when > touching FPU multiple times, otherwise, when terminated before second > FPU-interacation, it OOPSes on next invocation, stumbling over invalid > CPU state from prior invocation. With improved code, I can rather > reliably bring CPU into that state, so that next process invoked and > touching FPU/MMX-state is OOPSed. Currently searching SUID-binaries and > running UID=0 daemons, that might show interesting reaction on that > event, but only on DOS level yet, e.g. after running V2 test program > once and then connecting via SSH, this currently kills the ssh daemon > nicely. > > It seems that machine lockup occurs when e.g. switch to idle task > happens at exactly the right moment, which I currently cannot trigger on > real hardware, but still working on that. > I'm still wondering if this is a VirtualBox-specific problem or if it is something that *could* occur on hardware, or in other virtualization environments (KVM, Xen HVM, Hy-perV, VMware etc.) -hpa ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Sanitize CPU-state when switching from virtual-8086 mode to other task 2013-12-31 18:42 ` H. Peter Anvin @ 2013-12-31 19:21 ` Konrad Rzeszutek Wilk 2013-12-31 22:40 ` H. Peter Anvin 0 siblings, 1 reply; 24+ messages in thread From: Konrad Rzeszutek Wilk @ 2013-12-31 19:21 UTC (permalink / raw) To: H. Peter Anvin; +Cc: halfdog, Thomas Gleixner, Ingo Molnar, x86, linux-kernel On Tue, Dec 31, 2013 at 10:42:47AM -0800, H. Peter Anvin wrote: > On 12/30/2013 07:52 AM, halfdog wrote: > >> > >> Still in VirtualBox? > > > > Yes, again: after comparing the results from initrd on real hardware > > with Vbox, I'm getting to understand the timing problem involved and why > > timing in VBox is different: The test program usually OOPSes when > > touching FPU multiple times, otherwise, when terminated before second > > FPU-interacation, it OOPSes on next invocation, stumbling over invalid > > CPU state from prior invocation. With improved code, I can rather > > reliably bring CPU into that state, so that next process invoked and > > touching FPU/MMX-state is OOPSed. Currently searching SUID-binaries and > > running UID=0 daemons, that might show interesting reaction on that > > event, but only on DOS level yet, e.g. after running V2 test program > > once and then connecting via SSH, this currently kills the ssh daemon > > nicely. > > > > It seems that machine lockup occurs when e.g. switch to idle task > > happens at exactly the right moment, which I currently cannot trigger on > > real hardware, but still working on that. > > > > I'm still wondering if this is a VirtualBox-specific problem or if it is > something that *could* occur on hardware, or in other virtualization > environments (KVM, Xen HVM, Hy-perV, VMware etc.) So, I am wondering if this is related to " x86/fpu: CR0.TS should be set before trap into PV guest's #NM exception handle" which does have a similar pattern - you do enough of the task switches and the FPU is screwed. See http://mid.gmane.org/1383720072-6242-1-git-send-email-gaoyang.zyh@taobao.com (I thought there was a thread about this on LKML too but I can't find it). > > -hpa > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Sanitize CPU-state when switching from virtual-8086 mode to other task 2013-12-31 19:21 ` Konrad Rzeszutek Wilk @ 2013-12-31 22:40 ` H. Peter Anvin 2014-01-03 23:07 ` Sanitize FPU-state when switching tasks (was sanitize CPU-state when switching from virtual-8086 mode to other task) halfdog 2014-01-08 7:45 ` Sanitize CPU-state " halfdog 0 siblings, 2 replies; 24+ messages in thread From: H. Peter Anvin @ 2013-12-31 22:40 UTC (permalink / raw) To: Konrad Rzeszutek Wilk Cc: halfdog, Thomas Gleixner, Ingo Molnar, x86, linux-kernel On 12/31/2013 11:21 AM, Konrad Rzeszutek Wilk wrote: > > So, I am wondering if this is related to " x86/fpu: CR0.TS should be set before trap > into PV guest's #NM exception handle" which does have a similar pattern - you > do enough of the task switches and the FPU is screwed. > > See http://mid.gmane.org/1383720072-6242-1-git-send-email-gaoyang.zyh@taobao.com > > (I thought there was a thread about this on LKML too but I can't > find it). That would be a bug in Xen, so I guess you're surmising a similar bug in VirtualBox? -hpa ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Sanitize FPU-state when switching tasks (was sanitize CPU-state when switching from virtual-8086 mode to other task) 2013-12-31 22:40 ` H. Peter Anvin @ 2014-01-03 23:07 ` halfdog 2014-01-08 7:45 ` Sanitize CPU-state " halfdog 1 sibling, 0 replies; 24+ messages in thread From: halfdog @ 2014-01-03 23:07 UTC (permalink / raw) To: H. Peter Anvin, Konrad Rzeszutek Wilk Cc: Thomas Gleixner, Ingo Molnar, x86, linux-kernel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 H. Peter Anvin wrote: > On 12/31/2013 11:21 AM, Konrad Rzeszutek Wilk wrote: >> >> So, I am wondering if this is related to " x86/fpu: CR0.TS should >> be set before trap into PV guest's #NM exception handle" which >> does have a similar pattern - you do enough of the task switches >> and the FPU is screwed. >> >> See >> http://mid.gmane.org/1383720072-6242-1-git-send-email-gaoyang.zyh@taobao.com >> >> >> (I thought there was a thread about this on LKML too but I can't >> find it). > > That would be a bug in Xen, so I guess you're surmising a similar > bug in VirtualBox? Not sure on that yet, but the whole thing is getting even more funnier, the longer I can play with it. Here is some more information from my latest tests: * Although first observed with virtual-8086 mode, the bug is not specific to virtual-8086 mode, it can be triggered with normal x86 userspace code also, even with better reproducibility. * It seems, that when changing the FPU control word with "fstcw" just before exit of the process, then another process could suffer when doing __do_switch * By having two rogue processes writing data to each other via a socket, time and code-position of OOPS can be influenced. * When deactivating mmap_min_addr, the NULL-dereferences during task-switch are exploitable, but I did not get full ring-0 code execution yet, putting EIP to the NULL-seg seem to have failed, perhaps wrong RPL? Hoping to fix that during next days. You can find the new improved test code at [1]. hd [1] http://www.halfdog.net/Security/2013/Vm86SyscallTaskSwitchKernelPanic/FpuStateTaskSwitchOops.c - -- http://www.halfdog.net/ PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlLHQrwACgkQxFmThv7tq+4C+wCfZ0a0LhaJqI7DW78ZFGbnzIyu 6H8AnROrUklhvdbAGV5+7/ELEzPikU7T =jKjH -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Sanitize CPU-state when switching tasks (was sanitize CPU-state when switching from virtual-8086 mode to other task) 2013-12-31 22:40 ` H. Peter Anvin 2014-01-03 23:07 ` Sanitize FPU-state when switching tasks (was sanitize CPU-state when switching from virtual-8086 mode to other task) halfdog @ 2014-01-08 7:45 ` halfdog 2014-01-08 17:42 ` H. Peter Anvin 1 sibling, 1 reply; 24+ messages in thread From: halfdog @ 2014-01-08 7:45 UTC (permalink / raw) To: H. Peter Anvin, Konrad Rzeszutek Wilk Cc: Thomas Gleixner, Ingo Molnar, x86, linux-kernel, Ben Hutchings -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Update to the issue: * Although first observed with virtual-8086 mode, the bug is not specific to virtual-8086 mode, it can be triggered with normal x86 userspace code also, even with better reproducibility. * Ben Hutchings looked at the Debian bug report [1], he failed to reproduce on his hardware, so it might be specific to some CPU models (currently my AMD E-350 is only machine known to be affected). * When deactivating mmap_min_addr, the NULL-dereferences during task-switch is exploitable, works both on native hardware and within VirtualBox. See [2] for POC to gain root privileges. * It seems, that when changing the FPU control word with "fstcw" just before exit of the process, then another process could suffer when doing __do_switch, probably related to the xsave instruction and a x86 processor bug workaround, see "noxsave" switch [3]: [BUGS=X86] Disables x86 extended register state save and restore using xsave. The kernel will fallback to enabling legacy floating-point and sse state. hd [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733551 [2] http://www.halfdog.net/Security/2013/Vm86SyscallTaskSwitchKernelPanic/ [3] https://www.kernel.org/doc/Documentation/kernel-parameters.txt - -- http://www.halfdog.net/ PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlLNAjEACgkQxFmThv7tq+44FACfeDHQHK71+7tZawm9Ftjw7Hvp j04AmwY04UwG9clERS3e1HisM2swbo1i =KoQL -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Sanitize CPU-state when switching tasks (was sanitize CPU-state when switching from virtual-8086 mode to other task) 2014-01-08 7:45 ` Sanitize CPU-state " halfdog @ 2014-01-08 17:42 ` H. Peter Anvin 2014-01-08 19:36 ` Borislav Petkov 0 siblings, 1 reply; 24+ messages in thread From: H. Peter Anvin @ 2014-01-08 17:42 UTC (permalink / raw) To: halfdog, Konrad Rzeszutek Wilk Cc: Thomas Gleixner, Ingo Molnar, x86, linux-kernel, Ben Hutchings, Borislav Petkov Adding Borislav. Boris, do you happen to know of any erratum on AMD E-350 which may be in play here? -hpa On 01/07/2014 11:45 PM, halfdog wrote: > Update to the issue: > > * Although first observed with virtual-8086 mode, the bug is not > specific to virtual-8086 mode, it can be triggered with normal x86 > userspace code also, even with better reproducibility. > > * Ben Hutchings looked at the Debian bug report [1], he failed to > reproduce on his hardware, so it might be specific to some CPU > models (currently my AMD E-350 is only machine known to be > affected). > > * When deactivating mmap_min_addr, the NULL-dereferences during > task-switch is exploitable, works both on native hardware and > within VirtualBox. See [2] for POC to gain root privileges. > > * It seems, that when changing the FPU control word with "fstcw" > just before exit of the process, then another process could suffer > when doing __do_switch, probably related to the xsave instruction > and a x86 processor bug workaround, see "noxsave" switch [3]: > [BUGS=X86] Disables x86 extended register state save and restore > using xsave. The kernel will fallback to enabling legacy > floating-point and sse state. > > hd > > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733551 [2] > http://www.halfdog.net/Security/2013/Vm86SyscallTaskSwitchKernelPanic/ > > [3] https://www.kernel.org/doc/Documentation/kernel-parameters.txt > > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Sanitize CPU-state when switching tasks (was sanitize CPU-state when switching from virtual-8086 mode to other task) 2014-01-08 17:42 ` H. Peter Anvin @ 2014-01-08 19:36 ` Borislav Petkov 2014-01-08 21:28 ` halfdog 0 siblings, 1 reply; 24+ messages in thread From: Borislav Petkov @ 2014-01-08 19:36 UTC (permalink / raw) To: H. Peter Anvin Cc: halfdog, Konrad Rzeszutek Wilk, Thomas Gleixner, Ingo Molnar, x86, linux-kernel, Ben Hutchings On Wed, Jan 08, 2014 at 09:42:40AM -0800, H. Peter Anvin wrote: > Adding Borislav. > > Boris, do you happen to know of any erratum on AMD E-350 which may be > in play here? Interesting. Well, nothing looks even remotely related from looking at the F14h rev guide here: http://developer.amd.com/wordpress/media/2012/10/47534_14h_Mod_00h-0Fh_Rev_Guide.pdf Btw, hd (if that is your real name :-)), can you post /proc/cpuinfo? I think I might have a E-350 here too and I could try to reproduce. Btw, how exactly do you trigger? You run FpuStateTaskSwitchShmemXattrHandlersOverwriteWithNullPage.c first to modify shmem_xattr_handlers and then ManipulatedXattrHandlerForPrivEscalation.c? You need a 32-bit kernel and userspace, right? Anything else? Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Sanitize CPU-state when switching tasks (was sanitize CPU-state when switching from virtual-8086 mode to other task) 2014-01-08 19:36 ` Borislav Petkov @ 2014-01-08 21:28 ` halfdog 2014-01-08 22:39 ` H. Peter Anvin 2014-01-09 22:50 ` Sanitize CPU-state when switching tasks (was sanitize CPU-state when switching from virtual-8086 mode to other task) halfdog 0 siblings, 2 replies; 24+ messages in thread From: halfdog @ 2014-01-08 21:28 UTC (permalink / raw) To: Borislav Petkov, H. Peter Anvin Cc: Konrad Rzeszutek Wilk, Thomas Gleixner, Ingo Molnar, x86, linux-kernel, Ben Hutchings -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Borislav Petkov wrote: > On Wed, Jan 08, 2014 at 09:42:40AM -0800, H. Peter Anvin wrote: >> Adding Borislav. >> >> Boris, do you happen to know of any erratum on AMD E-350 which >> may be in play here? > > Interesting. Well, nothing looks even remotely related from looking > at the F14h rev guide here: > > http://developer.amd.com/wordpress/media/2012/10/47534_14h_Mod_00h-0Fh_Rev_Guide.pdf > > Btw, hd (if that is your real name :-)), can you post > /proc/cpuinfo? Of course (you can also find it in the Debian bug report [1]): processor : 0 vendor_id : AuthenticAMD cpu family : 20 model : 1 model name : AMD E-350 Processor stepping : 0 microcode : 0x5000028 cpu MHz : 1596.563 cache size : 512 KB fdiv_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 6 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc nonstop_tsc extd_apicid aperfmperf pni monitor ssse3 cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch ibs skinit wdt arat hw_pstate npt lbrv svm_lock nrip_save pausefilter bogomips : 3193.12 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate > I think I might have a E-350 here too and I could try to reproduce. > Btw, how exactly do you trigger? > > You run > FpuStateTaskSwitchShmemXattrHandlersOverwriteWithNullPage.c first > to modify shmem_xattr_handlers and then > ManipulatedXattrHandlerForPrivEscalation.c? You need a 32-bit > kernel and userspace, right? Anything else? Yes: I used the standard Debian Sid 468 kernel (32bit), the first tool might just trigger the OOPS to early, this seems to be harmless to the kernel, so one can invoke it until the handler pointer was modified. Since I hardcoded the Debian kernel addresses (copied from System.map), this is very unlikly to give you root on another kernel, but the math OOPS should be reproducible. Does this sound fishy (from [2])? "There is no need to save any active fpu state to the task structure memory if the task is dead. Just drop the state instead." My rogue process might interfere with that: change control registers, cause exception and then exit quickly Or could it be invalid CPU-features detection, perhaps related to [3]? The math-restore/__do_switch combination occurred already in older bug reports, e.g. [4] (very close), [5] (similar, poor info). )))OOPS "EIP is at math_state_restore"((( seems to be suitable search expression. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733551 [2] http://lkml.indiana.edu/hypermail/linux/kernel/1205.1/02182.html [3] http://lkml.indiana.edu/hypermail/linux/kernel/0905.2/02599.html [4] https://lkml.org/lkml/2008/6/16/146 [5] http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1536 - -- http://www.halfdog.net/ PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlLNww0ACgkQxFmThv7tq+4LngCeI/ZVFtzEy9RDpVP9Jk46tzGs 9h8Ani/YO9FsUOpcKxiXovJkTPiKuI4e =InkM -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Sanitize CPU-state when switching tasks (was sanitize CPU-state when switching from virtual-8086 mode to other task) 2014-01-08 21:28 ` halfdog @ 2014-01-08 22:39 ` H. Peter Anvin 2014-01-09 22:58 ` Borislav Petkov 2014-01-09 22:50 ` Sanitize CPU-state when switching tasks (was sanitize CPU-state when switching from virtual-8086 mode to other task) halfdog 1 sibling, 1 reply; 24+ messages in thread From: H. Peter Anvin @ 2014-01-08 22:39 UTC (permalink / raw) To: halfdog, Borislav Petkov Cc: Konrad Rzeszutek Wilk, Thomas Gleixner, Ingo Molnar, x86, linux-kernel, Ben Hutchings It is obviously critical here that we get a handle on if this is a CPU-specific problem that we might have to work around or a general problem with the Linux code. -hpa ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Sanitize CPU-state when switching tasks (was sanitize CPU-state when switching from virtual-8086 mode to other task) 2014-01-08 22:39 ` H. Peter Anvin @ 2014-01-09 22:58 ` Borislav Petkov 2014-01-10 0:42 ` Linus Torvalds 0 siblings, 1 reply; 24+ messages in thread From: Borislav Petkov @ 2014-01-09 22:58 UTC (permalink / raw) To: H. Peter Anvin Cc: halfdog, Konrad Rzeszutek Wilk, Thomas Gleixner, Ingo Molnar, x86, linux-kernel, Ben Hutchings On Wed, Jan 08, 2014 at 02:39:42PM -0800, H. Peter Anvin wrote: > It is obviously critical here that we get a handle on if this is a > CPU-specific problem that we might have to work around or a general > problem with the Linux code. Ok, I was able to reproduce with http://www.halfdog.net/Security/2013/Vm86SyscallTaskSwitchKernelPanic/FpuStateTaskSwitchShmemXattrHandlersOverwriteWithNullPage.c here on the latest linus+tip, see OOPS below: $ AFLAGS=--32 decodecode < ~/fpu.oops ... Code is: All code ======== 0: 89 d8 mov %ebx,%eax 2: e8 8c 96 00 00 call 0x9693 7: 85 c0 test %eax,%eax 9: 0f 85 9c 00 00 00 jne 0xab f: fa cli 10: e8 7e bd 08 00 call 0x8bd93 15: e9 6f 00 00 00 jmp 0x89 1a: c7 83 a0 02 00 00 01 movl $0x1,0x2a0(%ebx) 21: 00 00 00 24: 64 89 1d ac a7 8a c1 mov %ebx,%fs:0xc18aa7ac 2b:* 0f 77 emms <-- trapping instruction 2d: db 83 a0 02 00 00 fildl 0x2a0(%ebx) 33: 89 f6 mov %esi,%esi 35: 89 f6 mov %esi,%esi 37: eb 27 jmp 0x60 39: b8 ff ff ff ff mov $0xffffffff,%eax 3e: 8b .byte 0x8b 3f: bb .byte 0xbb Code starting with the faulting instruction =========================================== 0: 0f 77 emms 2: db 83 a0 02 00 00 fildl 0x2a0(%ebx) 8: 89 f6 mov %esi,%esi a: 89 f6 mov %esi,%esi c: eb 27 jmp 0x35 e: b8 ff ff ff ff mov $0xffffffff,%eax 13: 8b .byte 0x8b 14: bb .byte 0xbb which points at EMMS, which gets runtime-replaced in: static inline int restore_fpu_checking(struct task_struct *tsk) { /* AMD K7/K8 CPUs don't save/restore FDP/FIP/FOP unless an exception is pending. Clear the x87 state here by setting it to fixed values. "m" is a random variable that should be in L1 */ alternative_input( ASM_NOP8 ASM_NOP2, "emms\n\t" /* clear stack tags */ "fildl %P[addr]", /* set F?P to defined value */ X86_FEATURE_FXSAVE_LEAK, [addr] "m" (tsk->thread.fpu.has_fpu)); return fpu_restore_checking(&tsk->thread.fpu); } Now, judging by the exception type and if I'm not mistaken, we get an #MF which, according to the EMMS documentation means we get an #MF exception because an unmasked x87 floating-point exception was pending. Now, we most likely have done FXSAVE before that and this one doesn't check for pending unmasked x87 floating-point exceptions and we have CR0.NE=1b which means in that case that a numeric exception gets generated. Yadda, yadda, all is fine but why do we have any pending x87 FPU exceptions then where we shouldn't? I dunno - I've never warmed up to the FPU diddling in the kernel. I'll try to wrap my head around this later... --- localhost vmunix: [ 364.177380] fpu exception: 0000 [#1] PREEMPT SMP localhost vmunix: [ 364.185005] Modules linked in: ipv6 radeon snd_hda_codec_conexant rtl8192ce rtl_pci snd_hda_codec_hdmi rtlwifi snd_hda_intel mac80211 snd_hda_codec snd_hwdep usbhid snd_pcm cfg80211 rtsx_pci_sdmmc snd_page_alloc drm_kms_helper mmc_core snd_timer rtsx_pci rtl8192c_common ttm thinkpad_acpi nvram snd ohci_pci ehci_pci ohci_hcd mfd_core button ac video battery ehci_hcd pcspkr thermal k10temp soundcore localhost vmunix: [ 364.209743] CPU: 1 PID: 1200 Comm: find Tainted: G W 3.13.0-rc7+ #4 localhost vmunix: [ 364.217947] Hardware name: LENOVO 30515QG/30515QG, BIOS 8RET30WW (1.12 ) 09/15/2011 localhost vmunix: [ 364.226231] task: f4104980 ti: f3800000 task.ti: f3800000 localhost vmunix: [ 364.234511] EIP: 0060:[<c10026b8>] EFLAGS: 00010002 CPU: 1 localhost vmunix: [ 364.242734] EIP is at math_state_restore+0x48/0x1a0 localhost vmunix: [ 364.250939] EAX: f3801fb4 EBX: f4104980 ECX: 0000007b EDX: ffffffff localhost vmunix: [ 364.259188] ESI: 089c58f8 EDI: c1003510 EBP: f3801fa0 ESP: f3801f98 localhost vmunix: [ 364.267364] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 localhost vmunix: [ 364.275542] CR0: 80050033 CR2: b75d6f32 CR3: 331f9000 CR4: 000007d0 localhost vmunix: [ 364.283758] Stack: localhost vmunix: [ 364.291834] f3801fb4 c1003510 f3801fac c1003535 089c39f8 bf8b8e88 c155c96b 089c39f8 localhost vmunix: [ 364.300213] 00000000 00000029 089c58f8 00000000 bf8b8e88 080681fc 0000007b 0000007b localhost vmunix: [ 364.308631] 00000000 c1003510 ffffffff 0805e0f8 00000073 00010206 bf8b8e30 0000007b localhost vmunix: [ 364.316985] Call Trace: localhost vmunix: [ 364.325104] [<c1003510>] ? smp_thermal_interrupt+0x20/0x20 localhost vmunix: [ 364.333300] [<c1003535>] do_device_not_available+0x25/0x40 localhost vmunix: [ 364.341458] [<c155c96b>] error_code+0x5f/0x64 localhost vmunix: [ 364.349541] [<c1003510>] ? smp_thermal_interrupt+0x20/0x20 localhost vmunix: [ 364.357649] Code: 89 d8 e8 8c 96 00 00 85 c0 0f 85 9c 00 00 00 fa e8 7e bd 08 00 e9 6f 00 00 00 c7 83 a0 02 00 00 01 00 00 00 64 89 1d ac a7 8a c1 <0f> 77 db 83 a0 02 00 00 89 f6 89 f6 eb 27 b8 ff ff ff ff 8b bb localhost vmunix: [ 364.375367] EIP: [<c10026b8>] math_state_restore+0x48/0x1a0 SS:ESP 0068:f3801f98 localhost vmunix: [ 364.383830] ---[ end trace c8241b0abe86a792 ]--- -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Sanitize CPU-state when switching tasks (was sanitize CPU-state when switching from virtual-8086 mode to other task) 2014-01-09 22:58 ` Borislav Petkov @ 2014-01-10 0:42 ` Linus Torvalds 2014-01-10 2:13 ` H. Peter Anvin 2014-01-12 3:22 ` [tip:x86/urgent] x86, fpu, amd: Clear exceptions in AMD FXSAVE workaround tip-bot for Linus Torvalds 0 siblings, 2 replies; 24+ messages in thread From: Linus Torvalds @ 2014-01-10 0:42 UTC (permalink / raw) To: Borislav Petkov Cc: H. Peter Anvin, halfdog, Konrad Rzeszutek Wilk, Thomas Gleixner, Ingo Molnar, the arch/x86 maintainers, Linux Kernel Mailing List, Ben Hutchings [-- Attachment #1: Type: text/plain, Size: 451 bytes --] On Fri, Jan 10, 2014 at 6:58 AM, Borislav Petkov <bp@alien8.de> wrote: > > Ok, I was able to reproduce Looking at this, I think this is just a bug in our restore_fpu_checking() hackery for X86_FEATURE_FXSAVE_LEAK.. Which also explains why it only triggers on E-350 - it's only relevant for those K7/K8 CPU's that use this. Maybe just add a fcnlex to before the emms? Something like this (TOTALLY UNTESTED!!) attached patch. Linus [-- Attachment #2: patch.diff --] [-- Type: text/plain, Size: 1070 bytes --] arch/x86/include/asm/fpu-internal.h | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/arch/x86/include/asm/fpu-internal.h b/arch/x86/include/asm/fpu-internal.h index c49a613c6452..cea1c76d49bf 100644 --- a/arch/x86/include/asm/fpu-internal.h +++ b/arch/x86/include/asm/fpu-internal.h @@ -293,12 +293,13 @@ static inline int restore_fpu_checking(struct task_struct *tsk) /* AMD K7/K8 CPUs don't save/restore FDP/FIP/FOP unless an exception is pending. Clear the x87 state here by setting it to fixed values. "m" is a random variable that should be in L1 */ - alternative_input( - ASM_NOP8 ASM_NOP2, - "emms\n\t" /* clear stack tags */ - "fildl %P[addr]", /* set F?P to defined value */ - X86_FEATURE_FXSAVE_LEAK, - [addr] "m" (tsk->thread.fpu.has_fpu)); + if (unlikely(static_cpu_has(X86_FEATURE_FXSAVE_LEAK))) { + asm volatile( + "fnclex\n\t" + "emms\n\t" + "fildl %P[addr]" /* set F?P to defined value */ + : : [addr] "m" (tsk->thread.fpu.has_fpu)); + } return fpu_restore_checking(&tsk->thread.fpu); } ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: Sanitize CPU-state when switching tasks (was sanitize CPU-state when switching from virtual-8086 mode to other task) 2014-01-10 0:42 ` Linus Torvalds @ 2014-01-10 2:13 ` H. Peter Anvin 2014-01-10 10:06 ` Borislav Petkov 2014-01-12 3:22 ` [tip:x86/urgent] x86, fpu, amd: Clear exceptions in AMD FXSAVE workaround tip-bot for Linus Torvalds 1 sibling, 1 reply; 24+ messages in thread From: H. Peter Anvin @ 2014-01-10 2:13 UTC (permalink / raw) To: Linus Torvalds, Borislav Petkov Cc: halfdog, Konrad Rzeszutek Wilk, Thomas Gleixner, Ingo Molnar, the arch/x86 maintainers, Linux Kernel Mailing List, Ben Hutchings On 01/09/2014 04:42 PM, Linus Torvalds wrote: > On Fri, Jan 10, 2014 at 6:58 AM, Borislav Petkov <bp@alien8.de> wrote: >> >> Ok, I was able to reproduce > > Looking at this, I think this is just a bug in our > restore_fpu_checking() hackery for X86_FEATURE_FXSAVE_LEAK.. > > Which also explains why it only triggers on E-350 - it's only relevant > for those K7/K8 CPU's that use this. > > Maybe just add a fcnlex to before the emms? Something like this > (TOTALLY UNTESTED!!) attached patch. > OK, that sounds very reasonable. Boris, halfdog, does something like this resolve your problem? -hpa ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Sanitize CPU-state when switching tasks (was sanitize CPU-state when switching from virtual-8086 mode to other task) 2014-01-10 2:13 ` H. Peter Anvin @ 2014-01-10 10:06 ` Borislav Petkov 2014-01-10 11:16 ` Linus Torvalds 0 siblings, 1 reply; 24+ messages in thread From: Borislav Petkov @ 2014-01-10 10:06 UTC (permalink / raw) To: H. Peter Anvin Cc: Linus Torvalds, halfdog, Konrad Rzeszutek Wilk, Thomas Gleixner, Ingo Molnar, the arch/x86 maintainers, Linux Kernel Mailing List, Ben Hutchings On Thu, Jan 09, 2014 at 06:13:19PM -0800, H. Peter Anvin wrote: > OK, that sounds very reasonable. Boris, halfdog, does something like > this resolve your problem? Yeah, if in doubt, Linus to the rescue! :) Tested-by: Borislav Petkov <bp@suse.de> -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Sanitize CPU-state when switching tasks (was sanitize CPU-state when switching from virtual-8086 mode to other task) 2014-01-10 10:06 ` Borislav Petkov @ 2014-01-10 11:16 ` Linus Torvalds 2014-01-10 11:34 ` Borislav Petkov 2014-01-10 16:11 ` H. Peter Anvin 0 siblings, 2 replies; 24+ messages in thread From: Linus Torvalds @ 2014-01-10 11:16 UTC (permalink / raw) To: Borislav Petkov Cc: H. Peter Anvin, halfdog, Konrad Rzeszutek Wilk, Thomas Gleixner, Ingo Molnar, the arch/x86 maintainers, Linux Kernel Mailing List, Ben Hutchings On Fri, Jan 10, 2014 at 6:06 PM, Borislav Petkov <bp@alien8.de> wrote: > > Tested-by: Borislav Petkov <bp@suse.de> Ok, good. Peter, do you want to take it (feel free to add my sign-off), or should I just commit it? Also, is there a way to have a "likely not true" version of that "static_cpu_has()"? There seems to be no way to make the non-K7/K8 case the fallthrough code.. Not that this is likely that performance-critical, but.. Linus ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Sanitize CPU-state when switching tasks (was sanitize CPU-state when switching from virtual-8086 mode to other task) 2014-01-10 11:16 ` Linus Torvalds @ 2014-01-10 11:34 ` Borislav Petkov 2014-01-10 16:11 ` H. Peter Anvin 1 sibling, 0 replies; 24+ messages in thread From: Borislav Petkov @ 2014-01-10 11:34 UTC (permalink / raw) To: Linus Torvalds Cc: H. Peter Anvin, halfdog, Konrad Rzeszutek Wilk, Thomas Gleixner, Ingo Molnar, the arch/x86 maintainers, Linux Kernel Mailing List, Ben Hutchings On Fri, Jan 10, 2014 at 07:16:24PM +0800, Linus Torvalds wrote: > Also, is there a way to have a "likely not true" version of that > "static_cpu_has()"? There seems to be no way to make the non-K7/K8 > case FWIW, this is not only K7/K8 but actually all AMD from family 6 onwards, which is - practically speaking - all AMD. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Sanitize CPU-state when switching tasks (was sanitize CPU-state when switching from virtual-8086 mode to other task) 2014-01-10 11:16 ` Linus Torvalds 2014-01-10 11:34 ` Borislav Petkov @ 2014-01-10 16:11 ` H. Peter Anvin 1 sibling, 0 replies; 24+ messages in thread From: H. Peter Anvin @ 2014-01-10 16:11 UTC (permalink / raw) To: Linus Torvalds, Borislav Petkov Cc: halfdog, Konrad Rzeszutek Wilk, Thomas Gleixner, Ingo Molnar, the arch/x86 maintainers, Linux Kernel Mailing List, Ben Hutchings On 01/10/2014 03:16 AM, Linus Torvalds wrote: > On Fri, Jan 10, 2014 at 6:06 PM, Borislav Petkov <bp@alien8.de> wrote: >> >> Tested-by: Borislav Petkov <bp@suse.de> > > Ok, good. > > Peter, do you want to take it (feel free to add my sign-off), or > should I just commit it? > > Also, is there a way to have a "likely not true" version of that > "static_cpu_has()"? There seems to be no way to make the non-K7/K8 > case the fallthrough code.. Not that this is likely that > performance-critical, but.. > I'll take it. We don't have a "likely not true" version of static_cpu_has() at this point... it would mean we couldn't do short jumps unfortunately (and they would still take the false path until alternatives run.) -hpa ^ permalink raw reply [flat|nested] 24+ messages in thread
* [tip:x86/urgent] x86, fpu, amd: Clear exceptions in AMD FXSAVE workaround 2014-01-10 0:42 ` Linus Torvalds 2014-01-10 2:13 ` H. Peter Anvin @ 2014-01-12 3:22 ` tip-bot for Linus Torvalds 1 sibling, 0 replies; 24+ messages in thread From: tip-bot for Linus Torvalds @ 2014-01-12 3:22 UTC (permalink / raw) To: linux-tip-commits; +Cc: linux-kernel, hpa, mingo, torvalds, tglx, bp, me Commit-ID: 26bef1318adc1b3a530ecc807ef99346db2aa8b0 Gitweb: http://git.kernel.org/tip/26bef1318adc1b3a530ecc807ef99346db2aa8b0 Author: Linus Torvalds <torvalds@linux-foundation.org> AuthorDate: Sat, 11 Jan 2014 19:15:52 -0800 Committer: H. Peter Anvin <hpa@zytor.com> CommitDate: Sat, 11 Jan 2014 19:15:52 -0800 x86, fpu, amd: Clear exceptions in AMD FXSAVE workaround Before we do an EMMS in the AMD FXSAVE information leak workaround we need to clear any pending exceptions, otherwise we trap with a floating-point exception inside this code. Reported-by: halfdog <me@halfdog.net> Tested-by: Borislav Petkov <bp@suse.de> Link: http://lkml.kernel.org/r/CA%2B55aFxQnY_PCG_n4=0w-VG=YLXL-yr7oMxyy0WU2gCBAf3ydg@mail.gmail.com Signed-off-by: H. Peter Anvin <hpa@zytor.com> --- arch/x86/include/asm/fpu-internal.h | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/arch/x86/include/asm/fpu-internal.h b/arch/x86/include/asm/fpu-internal.h index c49a613..cea1c76 100644 --- a/arch/x86/include/asm/fpu-internal.h +++ b/arch/x86/include/asm/fpu-internal.h @@ -293,12 +293,13 @@ static inline int restore_fpu_checking(struct task_struct *tsk) /* AMD K7/K8 CPUs don't save/restore FDP/FIP/FOP unless an exception is pending. Clear the x87 state here by setting it to fixed values. "m" is a random variable that should be in L1 */ - alternative_input( - ASM_NOP8 ASM_NOP2, - "emms\n\t" /* clear stack tags */ - "fildl %P[addr]", /* set F?P to defined value */ - X86_FEATURE_FXSAVE_LEAK, - [addr] "m" (tsk->thread.fpu.has_fpu)); + if (unlikely(static_cpu_has(X86_FEATURE_FXSAVE_LEAK))) { + asm volatile( + "fnclex\n\t" + "emms\n\t" + "fildl %P[addr]" /* set F?P to defined value */ + : : [addr] "m" (tsk->thread.fpu.has_fpu)); + } return fpu_restore_checking(&tsk->thread.fpu); } ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: Sanitize CPU-state when switching tasks (was sanitize CPU-state when switching from virtual-8086 mode to other task) 2014-01-08 21:28 ` halfdog 2014-01-08 22:39 ` H. Peter Anvin @ 2014-01-09 22:50 ` halfdog 2014-01-09 23:02 ` Borislav Petkov 1 sibling, 1 reply; 24+ messages in thread From: halfdog @ 2014-01-09 22:50 UTC (permalink / raw) To: Borislav Petkov, H. Peter Anvin Cc: Konrad Rzeszutek Wilk, Thomas Gleixner, Ingo Molnar, x86, linux-kernel, Ben Hutchings -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It took me some time to build me the Debian Sid testing environment for amd64 with the same quality, I have vor i386, but now it is ready. And it seems, that amd64 is also affected, but lockup is immediately (makes exploitation harder) Here is the OOPS from the serial console, again in __switch_to [ 498.783577] fpu exception: 0000 [#1] SMP [ 498.787054] Modules linked in: 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 fuse snd_pcm snd_page_alloc snd_timer snd soundcore i2c_piix4 psmouse pcspkr evdev serio_raw i2c_core parport_pc parport battery button ac ext4 crc16 mbcache jbd2 sd_mod crc_t10dif crct10dif_common sg sr_mod cdrom ata_generic virtio_net mptspi scsi_transport_spi ata_piix virtio_pci virtio_ring virtio mptscsih mptbase libata scsi_mod [ 498.787205] CPU: 0 PID: 1783 Comm: Test Not tainted 3.12-1-amd64 #1 Debian 3.12.6-2 [ 498.787205] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 498.787205] task: ffff88000cb18840 ti: ffff88000b454000 task.ti: ffff88000b454000 [ 498.787205] RIP: 0010:[<ffffffff81011730>] [<ffffffff81011730>] __switch_to+0x2d0/0x490 [ 498.787205] RSP: 0018:ffff88000e0c78b8 EFLAGS: 00010002 [ 498.787205] RAX: 0000000000000001 RBX: ffff88000e0b77c0 RCX: 00000000c0000100 [ 498.787205] RDX: 0000000000000000 RSI: 0000000051e3f800 RDI: 00000000c0000100 [ 498.787205] RBP: ffff88000cb18840 R08: 0000000000000000 R09: 0000000000003314 [ 498.787205] R10: 0000000000001746 R11: 000000000000000f R12: 0000000000000000 [ 498.787205] R13: 0000000000000000 R14: ffff88000fc11780 R15: 0000000000000000 [ 498.787205] FS: 00007fb651e3f800(0000) GS:ffff88000fc00000(0000) knlGS:0000000000000000 [ 498.787205] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 498.787205] CR2: 00007f72ddfcc990 CR3: 000000000e22d000 CR4: 00000000000006f0 [ 498.787205] Stack: [ 498.787205] ffff88000e0b7bc0 000000010fc14330 ffff88000b4efac0 ffff88000e0b77c0 [ 498.787205] ffff88000fc142c0 ffff88000b5d3b40 0000000000000000 ffff88000e0b77c0 [ 498.787205] ffffffff8148febe ffff88000e0b77c0 0000000000000086 00000000000142c0 [ 498.787205] Call Trace: [ 498.787205] Code: ff 66 2e 0f 1f 84 00 00 00 00 00 bf 7d 00 00 00 e8 e6 00 01 00 84 c0 0f 85 d7 fd ff ff 0f 06 66 66 90 66 90 e9 cb fd ff ff 66 90 <0f> 77 db 83 94 04 00 00 66 90 eb 74 b8 ff ff ff ff 48 8b bb 98 [ 498.787205] RIP [<ffffffff81011730>] __switch_to+0x2d0/0x490 [ 498.787205] RSP <ffff88000e0c78b8> [ 498.787205] ---[ end trace 3f873c38e16c8005 ]--- [ 498.787205] Fixing recursive fault but reboot is needed! I'll try to go the same line as before: understand it, write a local-root-exploit for it (I feel it somehow, that this might be really hard on that kernel) and test it on the bare hardware afterwards. - -- http://www.halfdog.net/ PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlLPJ7MACgkQxFmThv7tq+6CSACeK7/SBzJOVvLlVBas9NANZYFp pEUAn21LoX0ewsnOag7fomqtvKqUzGyL =pst0 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Sanitize CPU-state when switching tasks (was sanitize CPU-state when switching from virtual-8086 mode to other task) 2014-01-09 22:50 ` Sanitize CPU-state when switching tasks (was sanitize CPU-state when switching from virtual-8086 mode to other task) halfdog @ 2014-01-09 23:02 ` Borislav Petkov 0 siblings, 0 replies; 24+ messages in thread From: Borislav Petkov @ 2014-01-09 23:02 UTC (permalink / raw) To: halfdog Cc: H. Peter Anvin, Konrad Rzeszutek Wilk, Thomas Gleixner, Ingo Molnar, x86, linux-kernel, Ben Hutchings On Thu, Jan 09, 2014 at 10:50:28PM +0000, halfdog wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > It took me some time to build me the Debian Sid testing environment > for amd64 with the same quality, I have vor i386, but now it is ready. > And it seems, that amd64 is also affected, but lockup is immediately > (makes exploitation harder) > > Here is the OOPS from the serial console, again in __switch_to > > [ 498.783577] fpu exception: 0000 [#1] SMP > [ 498.787054] Modules linked in: 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 fuse snd_pcm snd_page_alloc > snd_timer snd soundcore i2c_piix4 psmouse pcspkr evdev serio_raw > i2c_core parport_pc parport battery button ac ext4 crc16 mbcache jbd2 > sd_mod crc_t10dif crct10dif_common sg sr_mod cdrom ata_generic > virtio_net mptspi scsi_transport_spi ata_piix virtio_pci virtio_ring > virtio mptscsih mptbase libata scsi_mod > [ 498.787205] CPU: 0 PID: 1783 Comm: Test Not tainted 3.12-1-amd64 #1 > Debian 3.12.6-2 > [ 498.787205] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS > VirtualBox 12/01/2006 > [ 498.787205] task: ffff88000cb18840 ti: ffff88000b454000 task.ti: > ffff88000b454000 > [ 498.787205] RIP: 0010:[<ffffffff81011730>] [<ffffffff81011730>] > __switch_to+0x2d0/0x490 > [ 498.787205] RSP: 0018:ffff88000e0c78b8 EFLAGS: 00010002 > [ 498.787205] RAX: 0000000000000001 RBX: ffff88000e0b77c0 RCX: > 00000000c0000100 > [ 498.787205] RDX: 0000000000000000 RSI: 0000000051e3f800 RDI: > 00000000c0000100 > [ 498.787205] RBP: ffff88000cb18840 R08: 0000000000000000 R09: > 0000000000003314 > [ 498.787205] R10: 0000000000001746 R11: 000000000000000f R12: > 0000000000000000 > [ 498.787205] R13: 0000000000000000 R14: ffff88000fc11780 R15: > 0000000000000000 > [ 498.787205] FS: 00007fb651e3f800(0000) GS:ffff88000fc00000(0000) > knlGS:0000000000000000 > [ 498.787205] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 498.787205] CR2: 00007f72ddfcc990 CR3: 000000000e22d000 CR4: > 00000000000006f0 > [ 498.787205] Stack: > [ 498.787205] ffff88000e0b7bc0 000000010fc14330 ffff88000b4efac0 > ffff88000e0b77c0 > [ 498.787205] ffff88000fc142c0 ffff88000b5d3b40 0000000000000000 > ffff88000e0b77c0 > [ 498.787205] ffffffff8148febe ffff88000e0b77c0 0000000000000086 > 00000000000142c0 > [ 498.787205] Call Trace: > [ 498.787205] Code: ff 66 2e 0f 1f 84 00 00 00 00 00 bf 7d 00 00 00 > e8 e6 00 01 00 84 c0 0f 85 d7 fd ff ff 0f 06 66 66 90 66 90 e9 cb fd > ff ff 66 90 <0f> 77 db 83 94 04 00 00 66 90 eb 74 b8 ff ff ff ff 48 8b Yep, EMMS again: 0f 77 - unhandled x87 FPU exception, see my other mail I just sent. I'll try this on another AMD machine tomorrow to see whether it is affected too. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2014-01-12 3:22 UTC | newest] Thread overview: 24+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-12-28 22:02 Sanitize CPU-state when switching from virtual-8086 mode to other task halfdog 2013-12-29 2:37 ` H. Peter Anvin 2013-12-29 20:44 ` halfdog 2013-12-30 1:18 ` H. Peter Anvin 2013-12-30 15:52 ` halfdog 2013-12-31 18:42 ` H. Peter Anvin 2013-12-31 19:21 ` Konrad Rzeszutek Wilk 2013-12-31 22:40 ` H. Peter Anvin 2014-01-03 23:07 ` Sanitize FPU-state when switching tasks (was sanitize CPU-state when switching from virtual-8086 mode to other task) halfdog 2014-01-08 7:45 ` Sanitize CPU-state " halfdog 2014-01-08 17:42 ` H. Peter Anvin 2014-01-08 19:36 ` Borislav Petkov 2014-01-08 21:28 ` halfdog 2014-01-08 22:39 ` H. Peter Anvin 2014-01-09 22:58 ` Borislav Petkov 2014-01-10 0:42 ` Linus Torvalds 2014-01-10 2:13 ` H. Peter Anvin 2014-01-10 10:06 ` Borislav Petkov 2014-01-10 11:16 ` Linus Torvalds 2014-01-10 11:34 ` Borislav Petkov 2014-01-10 16:11 ` H. Peter Anvin 2014-01-12 3:22 ` [tip:x86/urgent] x86, fpu, amd: Clear exceptions in AMD FXSAVE workaround tip-bot for Linus Torvalds 2014-01-09 22:50 ` Sanitize CPU-state when switching tasks (was sanitize CPU-state when switching from virtual-8086 mode to other task) halfdog 2014-01-09 23:02 ` Borislav Petkov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).