Summary: | virtualbox trigger kernel bug | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alex Efros <powerman-asdf> |
Component: | New packages | Assignee: | Patrick Lauer <patrick> |
Status: | RESOLVED NEEDINFO | ||
Severity: | major | CC: | pageexec, polynomial-c, swapon |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
-ose-3.0.12, using VT-x, with PaX&GrSecurity: kernel BUG at mm/mmap.c:1746
-bin-3.0.12, using VT-x, without PaX&GrSecurity: general protection fault -bin-3.0.12, without VT-x, without PaX&GrSecurity: general protection fault -bin-3.1.6, using VT-x, without PaX&GrSecurity: general protection fault -bin-3.1.6, using VT-x, with PaX&GrSecurity: kernel BUG at mm/mmap.c:1746 |
Description
Alex Efros
2010-04-07 01:07:32 UTC
Created attachment 226801 [details]
-ose-3.0.12, using VT-x, with PaX&GrSecurity: kernel BUG at mm/mmap.c:1746
Created attachment 226803 [details]
-bin-3.0.12, using VT-x, without PaX&GrSecurity: general protection fault
Created attachment 226805 [details]
-bin-3.0.12, without VT-x, without PaX&GrSecurity: general protection fault
Created attachment 226807 [details]
-bin-3.1.6, using VT-x, without PaX&GrSecurity: general protection fault
Created attachment 226809 [details]
-bin-3.1.6, using VT-x, with PaX&GrSecurity: kernel BUG at mm/mmap.c:1746
does this still happen with the latest vbox/PaX kernel combos? (In reply to comment #6) > does this still happen with the latest vbox/PaX kernel combos? Yeah. I've just tested kernel 2.6.32-hardened-r22 with virtual-box versions -bin-3.1.8, -bin-3.2.10-r1 and -ose-3.1.8: all hangs on starting new virtual machine and in all tests I see same kernel bug in log: <0>------------[ cut here ]------------ kern.crit: kernel BUG at mm/mmap.c:1774! <0>invalid opcode: 0000 [#1] SMP <0>last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host4/target4:0:0/4:0:0:0/block/sr1/dev kern.warn: Modules linked in: act_police cls_fw cls_u32 sch_ingress sch_tbf sch_sfq sch_prio sch_cbq sch_htb nvidia(P) vboxnetadp vboxnetflt vboxdrv sky2 8139too skge kern.warn: kern.warn: Pid: 4162, comm: VirtualBox Tainted: P (2.6.32-hardened-r22 #1) System Product Name kern.warn: EIP: 0060:[<c1084c70>] EFLAGS: 00010206 CPU: 0 kern.warn: EAX: 00000000 EBX: 00051000 ECX: 00000000 EDX: ee3f453c kern.warn: ESI: 02080000 EDI: edc39140 EBP: ec4bfc24 ESP: ec4bfc18 kern.warn: DS: 0068 ES: 0068 FS: 00d8 GS: 00e0 SS: 0068 <0>Process VirtualBox (pid: 4162, ti=ec4be000 task=ec598ce0 task.ti=ec4be000) <0>Stack: kern.warn: ec9a6b9c ef85189c 4352d000 ec4bfc68 c108681c 00000000 ec4bfca0 00000246 kern.warn: <0> 00000001 00000041 ffffffff 00000000 0000618f 000fffff 00000000 ef85189c kern.warn: <0> 4350d000 ef8518bc 4350d000 00000020 ec4bfcc4 c108731c 4352d000 000000ff <0>Call Trace: kern.warn: [<c108681c>] ? kern.warn: [<c108731c>] ? kern.warn: [<c1087a9c>] ? kern.warn: [<f83a6d5e>] ? kern.warn: [<f83a78d7>] ? ... kern.warn: [<c1003645>] ? <0>Code: 75 29 5b 89 d0 5e 5f c9 c3 66 90 8b 70 5c 85 f6 75 15 5b 31 d2 5e 89 d0 5f c9 c3 0f 0b eb fe 0f 0b eb fe 0f 0b eb fe 0f 0b eb fe <0f> 0b eb fe 0f 0b eb fe 81 fb 00 00 00 60 76 8a 0f 0b eb fe 0f <0>EIP: [<c1084c70>] SS:ESP 0068:ec4bfc18 kern.warn: ---[ end trace 0eb47bba3f532979 ]--- Also I've just tested on same workstation windows versions of both VirtualBox (VirtualBox-3.2.10-66523-Win.exe) and VMware (VMware-workstation-full-7.1.2-301548.exe). WinXP SP3 32-bit host run both 32-bit and 64-bit guests in VirtualBox and VMware without issues - so this isn't hardware issue with my CPU of something. No sure is this related, but in addition to this issue I've another one with VMware (only when using Hardened Gentoo 32-bit as host os): while it perfectly run 32-bit guests, attempt to run 64-bit guest lead to _host_os_reset_ (guest BIOS pass ok, guest os start booting, and shortly after that, I suppose when guest os switch CPU to 64-bit mode, host reset to BIOS without doing usual linux shutdown procedure). This happens only when VT-x (I've Core2Duo 6600) enabled in BIOS - without it VMware refuse to start 64-bit guests on 32-bit host. I'm now going to test virtualbox with hardened-sources-2.6.35-r5... I forget to add: virtualbox hangs in all configurations (32-bit and 64-bit guests; with enabled/disabled VT-x in virtualbox's guest config; with enabled/disabled VT-x in BIOS). (In reply to comment #7) > I'm now going to test virtualbox with hardened-sources-2.6.35-r5... Yeah, in 2.6.35-hardened-r5 I got same kernel bug, only line number changed: mm/mmap.c:1884. Switching off CONFIG_PAX_MEMORY_UDEREF fixed this bug! Both for VirtualBox and VMware. yesterday i finally had time to investigate these crashes and here's the summary. there are actually 3 bugs here, not just one. 1. vbox does some funky things with the userland address space from the kernel, such as creating rwx mappings and then populating the page tables from the kernel as well. the bug in PaX was that SEGMEXEC wasn't aware of these rwx mappings and the mirroring logic detected it as an inconsistency. this one is fixed in the latest PaX test patches for .35 and .36, i'll update .32 later today. 2. vbox has its own kernel module loader implementation which is incompatible with KERNEXEC/i386 (possibly amd64 too, i didn't try there) and can't be fixed on the PaX side. 3. vboxdrv (or more likely, some runtime generated code from there) accesses userland directly without using the proper accessors which is then caught by UDEREF. this is a vbox bug (probably a security bug actually since the logged in user must be able to access the underlying device and issue the ioctl that triggers UDEREF), so again i can't fix in PaX. pageexec would you be so kind and report this upstream? I doubt I understand the whole matter enough to submit the correct information to VBox-upstream. Please reopen if this is still an issue with latest virtualbox versions in tree. (In reply to comment #13) > Please reopen if this is still an issue with latest virtualbox versions in > tree. Sorry, I can't test that. Some time ago I've moved to 64-bit, and since that time neither VMware nor VirtualBox work (on hardened) at all - see bug 404155 and bug 382793. |