When running VirtualBox 3.2.12, the GUI starts up fine, but as soon as one starts a vm. Using netconsole, I caught the panic from an amd64 box: Jan 3 17:08:20 yellowness Pid: 18578, comm: VirtualBox Not tainted 2.6.36-hardened-r6 #1 P6T/System Product Name Jan 3 17:08:20 yellowness RIP: 0010:[<ffffffffa08f1297>] Jan 3 17:08:20 yellowness [<ffffffffa08f1297>] g_abExecMemory+0xa297/0x18490c [vboxdrv] Jan 3 17:08:20 yellowness RSP: 0018:ffff88031a0f7b40 EFLAGS: 00010082 Jan 3 17:08:20 yellowness RAX: ffffffff81681040 RBX: 0000000000000040 RCX: 0000000000000000 Jan 3 17:08:20 yellowness RDX: 0000000000000600 RSI: 0000000000000000 RDI: ffffc90012ead780 Jan 3 17:08:20 yellowness RBP: 0000000000000000 R08: ffffc90012ead000 R09: 0000005caa0d7bf7 Jan 3 17:08:20 yellowness R10: ffffffffa08f1230 R11: 0000010b3fce34cc R12: ffffc90012ead780 Jan 3 17:08:20 yellowness R13: ffffc90012e92000 R14: ffffc90012eaddc4 R15: ffffc90012ead004 Jan 3 17:08:20 yellowness FS: 0000034f6e308710(0000) GS:ffff880002240000(0000) knlGS:0000000000000000 Jan 3 17:08:20 yellowness CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b Jan 3 17:08:20 yellowness CR2: ffffffff81681044 CR3: 0000000001637000 CR4: 00000000000026f0 Jan 3 17:08:20 yellowness DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Jan 3 17:08:20 yellowness DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Jan 3 17:08:20 yellowness Process VirtualBox (pid: 18578, threadinfo ffff88031a0f6000, task ffff88031528efa0) Jan 3 17:08:20 yellowness Stack: Jan 3 17:08:20 yellowness ffff81681000007f Jan 3 17:08:20 yellowness 000000000000ffff Jan 3 17:08:20 yellowness 0000000000000000 Jan 3 17:08:20 yellowness ffffc90012ead780 Jan 3 17:08:20 yellowness Jan 3 17:08:20 yellowness kernel: Jan 3 17:08:20 yellowness ffffc90012eade68 Jan 3 17:08:20 yellowness 0000000000000000 Jan 3 17:08:20 yellowness 0000000002240000 Jan 3 17:08:20 yellowness 00000000ffff8800 Jan 3 17:08:20 yellowness Jan 3 17:08:20 yellowness kernel: Jan 3 17:08:20 yellowness 0000000000000000 Jan 3 17:08:20 yellowness 000000006e308710 Jan 3 17:08:20 yellowness 000000000000034f Jan 3 17:08:20 yellowness 0000000000000000 Jan 3 17:08:20 yellowness Jan 3 17:08:20 yellowness Call Trace: Jan 3 17:08:20 yellowness [<ffffffff8106681d>] ? select_task_rq_fair+0x4fd/0x890 Jan 3 17:08:20 yellowness [<ffffffffa078cbb2>] ? supdrvIOCtlFast+0x72/0x280 [vboxdrv] Jan 3 17:08:20 yellowness [<ffffffffa078c2f9>] ? SUPR0Printf+0x119/0x530 [vboxdrv] Jan 3 17:08:20 yellowness [<ffffffff81107a8f>] ? do_sync_write+0xbf/0x100 Jan 3 17:08:20 yellowness [<ffffffff81119707>] ? do_vfs_ioctl+0xb7/0x780 Jan 3 17:08:20 yellowness [<ffffffff8160df75>] ? schedule+0x9e5/0xac0 Jan 3 17:08:20 yellowness [<ffffffff81119e19>] ? sys_ioctl+0x49/0x80 Jan 3 17:08:20 yellowness [<ffffffff8102edcb>] ? system_call_fastpath+0x16/0x1b Jan 3 17:08:20 yellowness Code: Jan 3 17:08:20 yellowness 00 Jan 3 17:08:20 yellowness 00 Jan 3 17:08:20 yellowness 36 Jan 3 17:08:20 yellowness 89 Jan 3 17:08:20 yellowness b7 Jan 3 17:08:20 yellowness 08 Jan 3 17:08:20 yellowness 02 Jan 3 17:08:20 yellowness 00 Jan 3 17:08:20 yellowness 00 Jan 3 17:08:20 yellowness 36 Jan 3 17:08:20 yellowness 89 Jan 3 17:08:20 yellowness af Jan 3 17:08:20 yellowness 10 Jan 3 17:08:20 yellowness 02 Jan 3 17:08:20 yellowness 00 Jan 3 17:08:20 yellowness 00 Jan 3 17:08:20 yellowness 58 Jan 3 17:08:20 yellowness 36 Jan 3 17:08:20 yellowness 89 Jan 3 17:08:20 yellowness 87 Jan 3 17:08:20 yellowness 00 Jan 3 17:08:20 yellowness 02 Jan 3 17:08:20 yellowness 00 Jan 3 17:08:20 yellowness 00 Jan 3 17:08:20 yellowness 5b Jan 3 17:08:20 yellowness 48 Jan 3 17:08:20 yellowness 83 Jan 3 17:08:20 yellowness ec Jan 3 17:08:20 yellowness 10 Jan 3 17:08:20 yellowness 0f Jan 3 17:08:20 yellowness 01 Jan 3 17:08:20 yellowness 04 Jan 3 17:08:20 yellowness 24 Jan 3 17:08:20 yellowness 48 Jan 3 17:08:20 yellowness 89 Jan 3 17:08:20 yellowness d8 Jan 3 17:08:20 yellowness 24 Jan 3 17:08:20 yellowness f8 Jan 3 17:08:20 yellowness 48 Jan 3 17:08:20 yellowness 03 Jan 3 17:08:20 yellowness 44 Jan 3 17:08:20 yellowness 24 Jan 3 17:08:20 yellowness 02 Jan 3 17:08:20 yellowness Jan 3 17:08:20 yellowness 81 Jan 3 17:08:20 yellowness 60 Jan 3 17:08:20 yellowness 04 Jan 3 17:08:20 yellowness ff Jan 3 17:08:20 yellowness fd Jan 3 17:08:20 yellowness ff Jan 3 17:08:20 yellowness ff Jan 3 17:08:20 yellowness 0f Jan 3 17:08:20 yellowness 00 Jan 3 17:08:20 yellowness db Jan 3 17:08:20 yellowness 48 Jan 3 17:08:20 yellowness 83 Jan 3 17:08:20 yellowness c4 Jan 3 17:08:20 yellowness 10 Jan 3 17:08:20 yellowness 58 Jan 3 17:08:20 yellowness 0f Jan 3 17:08:20 yellowness 00 Jan 3 17:08:20 yellowness d0 Jan 3 17:08:20 yellowness 48 Jan 3 17:08:20 yellowness 83 Jan 3 17:08:20 yellowness Jan 3 17:08:20 yellowness RIP Jan 3 17:08:20 yellowness [<ffffffffa08f1297>] g_abExecMemory+0xa297/0x18490c [vboxdrv] Jan 3 17:08:20 yellowness RSP <ffff88031a0f7b40> Jan 3 17:08:20 yellowness CR2: ffffffff81681044 Jan 3 17:08:20 yellowness ---[ end trace 9adf8ff8e8798eea ]--- Jan 3 17:08:20 yellowness note: VirtualBox[18578] exited with preempt_count 1
(In reply to comment #0) > When running VirtualBox 3.2.12, the GUI starts up fine, but as soon as one > starts a vm. Using netconsole, I caught the panic from an amd64 box: > Jan 3 17:08:20 yellowness RIP > Jan 3 17:08:20 yellowness [<ffffffffa08f1297>] g_abExecMemory+0xa297/0x18490c > [vboxdrv] > Jan 3 17:08:20 yellowness RSP <ffff88031a0f7b40> > Jan 3 17:08:20 yellowness CR2: ffffffff81681044 this is some vbox code trying to modify read-only memory under KERNEXEC, probably something in the GDT (you can check where rax falls based on System.map). so you can either disable KERNEXEC or find the offending code in one of the runtime loaded vbox modules and add the proper open/close kernel annotations. i don't quite feel like hunting this down myself, so feel free to let upstream figure it out ;).
> > so feel free to > let upstream figure it out ;). > Reported upstream: http://www.virtualbox.org/ticket/7996
Currently this bug is being mitigated in hardened-gentoo by disabling KERNEXEC via the predefined grsec/pax configuration VIRTUALIZATION. I'll leave this bug open in the off chance that upstream might act on it.
Probably related: If CONFIG_DEBUG_SET_MODULE_RONX is set, the kernel panics as soon as the VirtualBox modules are loaded.
hardened-sources-2.6.36-r6 was just removed from the tree.