Latest test patch kill qemu with KVM enabled

Discuss usability issues, general maintenance, and general support issues for a grsecurity-enabled system.

Latest test patch kill qemu with KVM enabled

Postby remnix » Sat Dec 21, 2013 3:59 am

Hi,

I am unable to start qemu with KVM enabled with kernel 3.12.5 and latest test grsec patch:
grsecurity-3.0-3.12.5-201312151212.patch

Here is the kernel msg :-

[ 337.166953] PAX: kernel memory leak attempt detected from c1c00000 (<kernel text>) (4096 bytes)
[ 337.166958] CPU: 1 PID: 2267 Comm: qemu-system-i38 Not tainted 3.12.5-granite #2
[ 337.166960] Hardware name: LENOVO 4291SUZ/4291SUZ, BIOS 8DET56WW (1.26 ) 12/01/2011
[ 337.166961] c200a627 00000000 c1c00000 f4c35cf4 00720057 00001000 f4c35d2c 00153d9a
[ 337.166966] c1d7d8fc c1d74038 c1d980a3 c1c00000 c1d7403d 00001000 00000001 f56e4de0
[ 337.166969] c1d6dfc0 f2de2008 000feffd 00000000 f4c35d48 00007f0b f5558d10 4dc78000
[ 337.166973] Call Trace:
[ 337.166978] [<00720057>] dump_stack+0x41/0x52
[ 337.166982] [<00153d9a>] __check_object_size+0xda/0x140
[ 337.166986] [<000feffd>] ? filter_pred_u64+0x5d/0xd0
[ 337.166988] [<00007f0b>] kvm_write_guest_page+0x3b/0x90
[ 337.166990] [<000082b1>] kvm_clear_guest_page+0x31/0x40
[ 337.166993] [<000feffd>] ? filter_pred_u64+0x5d/0xd0
[ 337.166996] [<00038b8a>] vmx_set_tss_addr+0x9a/0x190
[ 337.166998] [<000feffd>] ? filter_pred_u64+0x5d/0xd0
[ 337.167001] [<00004111>] ? perf_trace_kvm_async_pf_nopresent_ready+0xb1/0xd0
[ 337.167004] [<00003000>] ? callchain_recursion+0x8/0x10
[ 337.167007] [<00017241>] kvm_arch_vm_ioctl+0x721/0xfb0
[ 337.167009] [<0000ae47>] ? kvm_irqfd+0x147/0x470
[ 337.167012] [<0000626d>] kvm_vm_ioctl+0x9d/0xa80
[ 337.167015] [<0000ae47>] ? kvm_irqfd+0x147/0x470
[ 337.167017] [<000061d0>] ? kvm_set_memory_region+0x30/0x30
[ 337.167020] [<0015f710>] do_vfs_ioctl+0x400/0x6b0
[ 337.167023] [<0015f9fa>] SyS_ioctl+0x3a/0x70
[ 337.167025] [<0000ae47>] ? kvm_irqfd+0x147/0x470
[ 337.167028] [<00728319>] syscall_call+0x7/0xb
[ 337.167030] [<0000ae47>] ? kvm_irqfd+0x147/0x470
[ 337.167034] [<00070033>] ? do_sys_vm86+0x93/0x220
[ 337.167037] [<00010217>] ? perf_trace_kvm_inj_virq+0x77/0xc0
[ 337.168080] ------------[ cut here ]------------
[ 337.168088] WARNING: CPU: 1 PID: 2267 at kernel/srcu.c:285 cleanup_srcu_struct+0x69/0x70()
[ 337.168091] CPU: 1 PID: 2267 Comm: qemu-system-i38 Not tainted 3.12.5-granite #2
[ 337.168093] Hardware name: LENOVO 4291SUZ/4291SUZ, BIOS 8DET56WW (1.26 ) 12/01/2011
[ 337.168094] c200a627 00000000 c1d6b1ee f4c35bb4 00720057 00000000 f4c35be4 0007e274
[ 337.168100] c1d65940 00000001 000008db c1d6b1ee 0000011d 000a1e59 000a1e59 c1d6b1ee
[ 337.168105] 0000011d c2061c6c f4c35bfc 0007e347 00000009 00000000 00000001 f2de202c
[ 337.168110] Call Trace:
[ 337.168114] [<00720057>] dump_stack+0x41/0x52
[ 337.168119] [<0007e274>] warn_slowpath_common+0x74/0x90
[ 337.168123] [<000a1e59>] ? cleanup_srcu_struct+0x69/0x70
[ 337.168126] [<000a1e59>] ? cleanup_srcu_struct+0x69/0x70
[ 337.168129] [<0007e347>] warn_slowpath_null+0x27/0x30
[ 337.168132] [<000a1e59>] cleanup_srcu_struct+0x69/0x70
[ 337.168137] [<00005516>] kvm_put_kvm+0x116/0x160
[ 337.168140] [<000055b7>] kvm_vm_release+0x17/0x20
[ 337.168144] [<0014e85d>] __fput+0xbd/0x1e0
[ 337.168148] [<0014e9bd>] ____fput+0xd/0x10
[ 337.168151] [<0009a209>] task_work_run+0x89/0xa0
[ 337.168155] [<000800f5>] do_exit+0x275/0x960
[ 337.168159] [<000445a0>] ? show_stack_log_lvl+0x50/0xc0
[ 337.168162] [<00080853>] do_group_exit+0x33/0xa0
[ 337.168166] [<00153da9>] __check_object_size+0xe9/0x140
[ 337.168170] [<000feffd>] ? filter_pred_u64+0x5d/0xd0
[ 337.168174] [<00007f0b>] kvm_write_guest_page+0x3b/0x90
[ 337.168177] [<000082b1>] kvm_clear_guest_page+0x31/0x40
[ 337.168180] [<000feffd>] ? filter_pred_u64+0x5d/0xd0
[ 337.168183] [<00038b8a>] vmx_set_tss_addr+0x9a/0x190
[ 337.168187] [<000feffd>] ? filter_pred_u64+0x5d/0xd0
[ 337.168191] [<00004111>] ? perf_trace_kvm_async_pf_nopresent_ready+0xb1/0xd0
[ 337.168194] [<00003000>] ? callchain_recursion+0x8/0x10
[ 337.168198] [<00017241>] kvm_arch_vm_ioctl+0x721/0xfb0
[ 337.168202] [<0000ae47>] ? kvm_irqfd+0x147/0x470
[ 337.168205] [<0000626d>] kvm_vm_ioctl+0x9d/0xa80
[ 337.168208] [<0000ae47>] ? kvm_irqfd+0x147/0x470
[ 337.168212] [<000061d0>] ? kvm_set_memory_region+0x30/0x30
[ 337.168216] [<0015f710>] do_vfs_ioctl+0x400/0x6b0
[ 337.168220] [<0015f9fa>] SyS_ioctl+0x3a/0x70
[ 337.168223] [<0000ae47>] ? kvm_irqfd+0x147/0x470
[ 337.168226] [<00728319>] syscall_call+0x7/0xb
[ 337.168229] [<0000ae47>] ? kvm_irqfd+0x147/0x470
[ 337.168233] [<00070033>] ? do_sys_vm86+0x93/0x220
[ 337.168238] [<00010217>] ? perf_trace_kvm_inj_virq+0x77/0xc0
[ 337.168240] ---[ end trace 340223f019a9ab0d ]---

The kernel doesn't panic, just kill qemu.

I compiled the same kernel config against vanilla kernel and qemuworked with KVM fine.
So, evidently the grsec patch has found a kernel bug or is itself to blame.

Please help with this issue and let me know if any additional info is needed.

kernel config : http://pastebin.com/j3Dc7hax
remnix
 
Posts: 3
Joined: Sat Dec 21, 2013 3:24 am

Re: Latest test patch kill qemu with KVM enabled

Postby PaX Team » Sat Dec 21, 2013 7:32 am

can you post your System.map (that of the host) or at least look up what kind of code/data is around 0xc1c00000? if it's the module area then also look at /proc/modules and /proc/vmallocinfo.
PaX Team
 
Posts: 2310
Joined: Mon Mar 18, 2002 4:35 pm

Re: Latest test patch kill qemu with KVM enabled

Postby remnix » Sat Dec 21, 2013 2:07 pm

Here is the System map data : c1c00000 R empty_zero_page
(The forum code tags have size limit. My map file is 1.6MB. Even pastebin declined that size. Lemme know if anything else needed from it)

Module loading is disabled.

I had the same empty_zero_page location erroring out for recent 3.12.x kernels with your latest test patches.
remnix
 
Posts: 3
Joined: Sat Dec 21, 2013 3:24 am

Re: Latest test patch kill qemu with KVM enabled

Postby PaX Team » Sat Dec 21, 2013 5:30 pm

thanks, that was all i needed, the culprit is kvm_clear_guest_page that tries to copy from empty_zero_page to a guest page to fake a memset on it when the kernel already has __clear_user for that purpose, so that's how i'll fix it.
PaX Team
 
Posts: 2310
Joined: Mon Mar 18, 2002 4:35 pm

Re: Latest test patch kill qemu with KVM enabled

Postby remnix » Sat Dec 21, 2013 7:25 pm

Thanks a lot for such a quick response. Much appreciated.
remnix
 
Posts: 3
Joined: Sat Dec 21, 2013 3:24 am

Re: Latest test patch kill qemu with KVM enabled

Postby spender » Sun Dec 22, 2013 11:42 am

Hi,

The new patch is up for you to test.

Thanks,
-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm


Return to grsecurity support

cron