On some x86 systems, v86d works correctly when using the x86emu backend (+x86emu), but fails when using lrmi (-x86emu). This bug is meant to track this issue and offload bug #212531.
Ok, I think I found a solution. Both testvbe and v86d segfaults if compiled with USE=-x86emu and Optimization greater than -O0. If compiled with -O0 instead of -O[123] (didn't test with -Os, but probably will segfault either), it works.
Created attachment 158969 [details] some output from gdb, v86d compiled with CFLAGS="-O1 -g3"
i've just debugged this problem (without having been aware of the gentoo bugs, doh), and it's a bug in klibc. i've just sent a mail to the klibc list, hasn't shown up in their archives yet. the basic issue is that the x86 specific code in klibc/usr/klibc/memmove.c has a bug where the 'std' isn't followed by a 'cld' at the end of the asm insns, that'll break the ABI and cause memory corruption on later string insns.
ok, it's there: http://www.zytor.com/pipermail/klibc/2008-July/002325.html
FYI, klibc 1.5.12 fixing this bug was released last night.
thank you, it't working with klibc 1.5.12 v86d-0.1.5 (-debug -x86emu) gcc-4.3.1-r1 gentoo-sources-2.6.25-r6 hardware: nvidia 8800gt core2 quad 32bit 8gb ram
For everyone affected, could you please upgrade to klibc-1.5.12-r1 and then install v86d-0.1.5.1? Is there anyone for whom that doesn't fix the problem?
Created attachment 160599 [details, diff] fix compatibility with NX and PaX can you please add this patch? it fixes a crash and makes it also compatible with PaX.
(In reply to comment #8) > can you please add this patch? it fixes a crash and makes it also compatible > with PaX. Sure, added in v86d-0.1.5.2. Thanks for the patch :)
While this might or might not be related to what this bug was originally about, there is a known issue that matches the general description of this bug. It was recently determined that support for high resolution timers in the kernel can break the vm86 mode (http://lkml.org/lkml/2008/7/7/241). You're affected if: - your system is x86 (32-bit) - v86d works with x86emu, but doesn't with -x86emu (lrmi) - v86d with -x86emu if you compile the kernel with CONFIG_HIGH_RES_TIMERS=n and CONFIG_SCHED_HRTICK=n Please write a comment if this seems to be the problem you're experiencing.
(In reply to comment #10) > While this might or might not be related to what this bug was originally about, > there is a known issue that matches the general description of this bug. yours is a different bug, it doesn't result in a segfault per se but some odd behaviour. i suggest that you open a new bug for this (and add me to CC please). > was recently determined that support for high resolution timers in the kernel > can break the vm86 mode (http://lkml.org/lkml/2008/7/7/241). You're affected > if: > > - your system is x86 (32-bit) > - v86d works with x86emu, but doesn't with -x86emu (lrmi) > - v86d with -x86emu if you compile the kernel with CONFIG_HIGH_RES_TIMERS=n and > CONFIG_SCHED_HRTICK=n > > Please write a comment if this seems to be the problem you're experiencing. i have all the above and see these messages, even though v86d works otherwise with all the necessary mode switches during kernel boot and vt/x11 transitions.
i think bug 222799 is more like it, and http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=31656519e132f6612584815f128c83976a9aaaef is supposed to be the fix.
(In reply to comment #11) > yours is a different bug, it doesn't result in a segfault per se but some odd > behaviour. i suggest that you open a new bug for this (and add me to CC > please). OK, we can do that. I there anyone for whom _this_ bug (v86d segfaults) isn't fixed with the latest versions of v86d and klibc?
btw, my fix for PaX is more like a quick workaround. ideally, that mmap request should be split in into two, one doing PROT_READ|PROT_WRITE on the vga memory area, and another would do PROT_READ|PROT_EXEC on the ROM area, then -z execheap could go away as well. would you do or accept such a change?
(In reply to comment #14) > btw, my fix for PaX is more like a quick workaround. ideally, that mmap request > should be split in into two, one doing PROT_READ|PROT_WRITE on the vga memory > area, and another would do PROT_READ|PROT_EXEC on the ROM area, then -z > execheap could go away as well. would you do or accept such a change? I'll do that since I already have plans to do some changes to the memory mapping code. Thanks for explaining what needs to be done :)
(In reply to comment #13) > I there anyone for whom _this_ bug (v86d segfaults) isn't fixed with the latest > versions of v86d and klibc? It doesn't work for me. Here's my kernel log: [ 0.367683] Program v86d tried to access /dev/mem between a0000->110000. [ 0.367683] v86d[325]: segfault at 7f4c69927000 ip 400da6 sp 7fff71942ee0 error 6 in v86d[400000+17000] [ 0.501028] Switched to high resolution mode on CPU 1 [ 0.505939] Switched to high resolution mode on CPU 0 [ 5.363349] uvesafb: Getting VBE info block failed (eax=0x4f00, err=1) [ 5.363393] uvesafb: vbe_init() failed with -22 [ 5.363437] uvesafb: probe of uvesafb.0 failed with error -22 I'm using gentoo-sources 2.6.26, klibc 1.5.12-r1 and v86d 0.1.6. I also tried to enable/disable x86emu USE flag but the result doesn't changes. My video card is an Intel 945GC.
(In reply to comment #13) > I there anyone for whom _this_ bug (v86d segfaults) isn't fixed with the latest > versions of v86d and klibc? I also still have this bug. This is my kernel log: Aug 15 14:49:54 catk v86d[31132]: segfault at 837d1 ip 00008341 sp 00000ffa error 4 in zero[10000+40000] Aug 15 14:49:54 catk uvesafb: VBE get state call failed (eax=0x4f04, err=1) Aug 15 14:49:54 catk v86d[31135]: segfault at 837d1 ip 00008341 sp 00000ffa error 4 in zero[10000+40000] Aug 15 14:49:54 catk uvesafb: mode switch failed (eax=0x4f02, err=1) I'm using gentoo-sources-2.6.25-r7 with v86d 1.6 (-x86emu -debug) and klibc 1.5.12-r1. My video card is an NVIDIA 6600GT using binary drivers 173.14.12
After many tries I finally *did* manage to make uvesafb to work for me. I simply used the stable version of all the pieces of software involved: kernel 2.6.25, klibc 1.5.8 and v86d 1.3. It's quite strange and IMHO this problem is a regression for kernel 2.6.26. Now the only problem I should fix is to embed a static version of 915resolution in the initramfs *with* v86d but this is another story... ;)
I had v86d segfaults with 2.6.25 (and always latest ~x86 klibc/v86d etc) and somehow with kernel 2.6.26-r1 it's fixed itself. I never tried to enable x86emu flag though.
I still have the v86d segfaults, last try was with kernel 2.6.27-rc1-mm1. recent klibc (1.5.12-r1) and v86d (0.1.6). System and Kernel are x86_64. Use of the x86emu flag doesn't change anything. Compiling v86d with different compiler versions (gcc 4.3.1, 4.1.2, 3.4.6-hardenednopiessp) didn't change anything as well. Using uvesafb as module didn't help either. v86d debug output: v86d: EBDA at 9b800-9ffff v86d: VBIOS at c0000-cd9ff v86d: task flags: 0x0c v86d: EAX=00004f04 EBX=00000000 ECX=0000000f EDX=00000001 v86d: ESP=00000000 EBP=00000000 ESI=00000000 EDI=00000000 v86d: task flags: 0x00 v86d: EAX=00004f02 EBX=00004111 ECX=00000000 EDX=00000000 v86d: ESP=00000000 EBP=00000000 ESI=00000000 EDI=00000000 v86d: Trying to access an unsupported memory region at e867e v86d[13222]: segfault at 0 ip 0000000000401106 sp 00007fff5296f6d0 error 4 in v86d[400000+19000] uvesafb: mode switch failed (eax=0x4f02, err=1) v86d: EBDA at 9b800-9ffff v86d: VBIOS at c0000-cd9ff v86d: task flags: 0x04 v86d: EAX=00004f04 EBX=00000000 ECX=0000000f EDX=00000002 v86d: ESP=00000000 EBP=00000000 ESI=00000000 EDI=00000000 v86d: Trying to access an unsupported memory region at e867e v86d[13225]: segfault at 0 ip 0000000000401106 sp 00007fff0a4fb250 error 4 in v86d[400000+19000] uvesafb: VBE state restore call failed (eax=0x4f04, err=1)
(In reply to comment #20) > v86d: Trying to access an unsupported memory region at e867e Could you please attach your /proc/iomem?
Created attachment 164139 [details] /proc/iomem Attached is my /proc/iomem. It is from kernel 2.6.27-rc4-git7 not from 2.6.27-mm1-rc1, but i guess that shouldn't matter....
Created attachment 164179 [details, diff] Patch for v86d to map 0xe0000 - 0xfffff. Could you please try to build v86d with this patch applied, and with the x86emu flag? Also, was there a version of the kernel/v86d for which uvesafb worked for you?
> Patch for v86d to map 0xe0000 - 0xfffff. > > Could you please try to build v86d with this patch applied, and with the x86emu > flag? Changing the systems bios size and adress worked! I should have taken a look at the v86d sources and i could have found that solution too :-/ But on the other hand it's your baby ;) > Also, was there a version of the kernel/v86d for which uvesafb worked for you? At the moment i can only be sure that kernel 2.6.24 worked, but i don't know which versions of v86d and klibc i used at that time. If it is of interest for you, i can try to find that out! Thanks for the good work! If console decorations will be enabled again (I'm missing that feature in 2.6.27) i'm absolutely happy!
(In reply to comment #24) > At the moment i can only be sure that kernel 2.6.24 worked, but i don't know > which versions of v86d and klibc i used at that time. If it is of interest for > you, i can try to find that out! OK, if it works with the patch I attached, then the last working kernel version isn't really that important. I need to figure out what's in the 0xe0000 - 0xeffff area on your system though and it would be helpful if you could provide me with: * output of lspci -vv * run `dd if=/dev/mem of=/tmp/dump bs=65536 skip=14 count=2` and attach /tmp/dump
Created attachment 164301 [details] memory dump
Created attachment 164303 [details] lspci -vv output of borked system
Forget that: > If console decorations will be enabled again (I'm > missing that feature in 2.6.27) as your last patch worked fine with 2.6.27. Sorry!
I get the same error as Stefan, but the patch you posted doesn't fix it... :( x86emu doesn't make a difference.
(In reply to comment #29) > I get the same error as Stefan, but the patch you posted doesn't fix it... :( > > x86emu doesn't make a difference. Can you please post the part of the kernel log with the segfault and debugging info from v86d?
Program v86d tried to access /dev/mem between a0000->110000. v86d[999]: segfault at 7fff10ea6000 ip 400f58 sp 7fff18ec0460 error 6 in v86d[400000+1a000] uvesafb: Getting VBE info block failed (eax=0x4f00, err=1) uvesafb: vbe_init() failed with -22 uvesafb: probe of uvesafb.0 failed with error -22 What debugging info? How do I find it?
(In reply to comment #31) > What debugging info? How do I find it? If you emerge v86d with the 'debug' USE flag, it will print additional info to the kernel log (lines like 'v86d: EAX=00004f04 EBX=00000000 ECX=0000000f EDX=00000001' in the previous comments).
(In reply to comment #31) > Program v86d tried to access /dev/mem between a0000->110000. that's the result of CONFIG_NONPROMISC_DEVMEM, you should not be mmap'ing that much memory, for BIOS access all you need is a readable/executable mapping of 0xc0000-0x100000, 0xa0000-0xc0000 is vga memory, you should map it as readable/writable if you really need it.
it is emerged with debug. That's all it outputs in dmesg when booting.
(In reply to comment #34) > it is emerged with debug. That's all it outputs in dmesg when booting. Can you please try that with uvesafb built as a module? That should help with the lack of the debugging info. Also please do all the testing with a v86d compiled with the 'x86emu' USE flag.
Created attachment 165875 [details, diff] a few more fixes to mmap handling here's a new fix that makes things work better under PaX and the bios area size fix is probably good for everyone else as well. PS: could you please update your public git repo every now and then ;)?
(In reply to comment #36) > here's a new fix that makes things work better under PaX and the bios area size > fix is probably good for everyone else as well. Wow, that was one stupid bug -- I'll make a new release right away. Thanks for the patch! > PS: could you please update your public git repo every now and then ;)? Sure. I've just moved the repo to or.cz, and I'll make sure it's kept up to date there.
(In reply to comment #37) > Sure. I've just moved the repo to or.cz, and I'll make sure it's kept up to > date there. thanks ;). btw, what is the reason that the /dev/zero mapping needs PROT_EXEC as well? what code do you generate into it? couldn't it be done statically (i.e., not requiring runtime code generation)?
(In reply to comment #38) > thanks ;). btw, what is the reason that the /dev/zero mapping needs PROT_EXEC > as well? what code do you generate into it? couldn't it be done statically > (i.e., not requiring runtime code generation)? It's basically a single instruction (halt in x86emu and an int call in lrmi) used to exit the virtual/simulated x86 mode. While this code can be included statically in the v86d binary, I'm not entirely sure how to remap it properly afterwards so that it can be used in the emulation. Why would that be better than just writing the opcodes into the mmapped memory? Actually, in case of x86emu PROT_EXEC can be dropped entirely, as the code is always run in a full emulator and is thus never directly executed.
(In reply to comment #39) > It's basically a single instruction (halt in x86emu and an int call in lrmi) > used to exit the virtual/simulated x86 mode. yes, i figured it out in the meantime ;). > While this code can be included statically in the v86d binary, I'm not entirely > sure how to remap it properly afterwards so that it can be used in the > emulation. if i'm not mistaken, you don't need this specific interrupt here, just a mechanism to exit v86 mode, so you could also use an invalid opcode or similar exception that can be triggered by code already present in the v86 mode executable address space: somewhere in the bios i'm sure you can find the proper opcode sequence, say my video BIOS is full of 'ff ff' (and if not, then fall back to runtime code generation or do a second file mmap instead). > Why would that be better than just writing the opcodes into the > mmapped memory? because in that case one can revoke the runtime code generation privilege from v86d, which is an important property for security (i'd refer you to the PaX docs that explain it in more detail). there're many people these days that run with such a default setup where runtime code generation is disabled, and they'd be happier if the exception list was one app smaller ;).
(In reply to comment #40) > if i'm not mistaken, you don't need this specific interrupt here, just a > mechanism to exit v86 mode, so you could also use an invalid opcode or similar > exception that can be triggered by code already present in the v86 mode > executable address space: somewhere in the bios i'm sure you can find the > proper opcode sequence, say my video BIOS is full of 'ff ff' (and if not, then > fall back to runtime code generation or do a second file mmap instead). I don't like either of these ideas very much, but I've come up with another one. Please see the attached patch and let me know if it works for you.
Created attachment 166045 [details, diff] Remove dynamically generated code from lrmi.
(In reply to comment #41) > I don't like either of these ideas very much, but I've come up with another > one. Please see the attached patch and let me know if it works for you. this works on linux only: iirc, the BSD kernels' ELF loader assumes a maximum of 2 PT_LOAD segments and will refuse to load this binary... what you can do is to incorporate this section/page into the main RE PT_LOAD segment and at runtime mmap it yourself. alternatively you can rebase the entire ELF file to be below 1MB, at least the linux/klibc variant is small enough for that, no idea about other versions though.
> this works on linux only: iirc, the BSD kernels' ELF loader assumes a maximum > of 2 PT_LOAD segments and will refuse to load this binary... what you can do is > to incorporate this section/page into the main RE PT_LOAD segment and at > runtime mmap it yourself. alternatively you can rebase the entire ELF file to > be below 1MB, at least the linux/klibc variant is small enough for that, no > idea about other versions though. While portability is always nice, I'm not sure there is much point in caring about it in this case. As far as I know, neither uvesafb, nor v86d are used on *BSD, and I don't see this changing any time soon. I guess there might be some point in just fixing lrmi and providing the fix upstream. But is lrmi actually used by any 3rd party applications on *BSD?
(In reply to comment #44) > While portability is always nice, I'm not sure there is much point in caring > about it in this case. As far as I know, neither uvesafb, nor v86d are used on > *BSD, and I don't see this changing any time soon. i just mentioned the BSDs because i saw code tailored to their v86 mode use and thought they were somehow supported (no idea if anyone uses v86d there). so if it's for linux only then your method will work fine. in fact, you can simplify it by moving the asm into a .c file, something like: asm(".pushsection .vm86_ret.text, \"ax\"\nint $0xff;.popsection"); > I guess there might be some point in just fixing lrmi and providing the fix > upstream. that too, and in the meantime why not patch sys-libs/lrmi in portage instead of incorporating your own copy of lrmi in v86d? > But is lrmi actually used by any 3rd party applications on *BSD? that i can't tell, but in the lrmi bugzilla there's an entry from a BSD user so presumably someone was using it at some point ;).
(In reply to comment #45) > i just mentioned the BSDs because i saw code tailored to their v86 mode use and > thought they were somehow supported (no idea if anyone uses v86d there). so if > it's for linux only then your method will work fine. in fact, you can simplify > it by moving the asm into a .c file, something like: > > asm(".pushsection .vm86_ret.text, \"ax\"\nint $0xff;.popsection"); Yup, I'll try something like that later today. > > I guess there might be some point in just fixing lrmi and providing the fix > > upstream. > > that too, and in the meantime why not patch sys-libs/lrmi in portage instead of > incorporating your own copy of lrmi in v86d? I'd very much like to do that, but it's not really possible because the lrmi I'm using in v86d is compiled against klibc (and the one in Portage is compiled against glibc of course). > that i can't tell, but in the lrmi bugzilla there's an entry from a BSD user so > presumably someone was using it at some point ;). Yeah. I'm asking about that because IIRC the lrmi in Portage isn't actually used by any other project (i.e. there is no other package that depends on it).
(In reply to comment #46) > I'd very much like to do that, but it's not really possible because the lrmi > I'm using in v86d is compiled against klibc (and the one in Portage is compiled > against glibc of course). maybe, if there's no current user of lrmi in portage anyway, make it link to klibc by default and use that in v86d in turn?
(In reply to comment #47) > maybe, if there's no current user of lrmi in portage anyway, make it link to > klibc by default and use that in v86d in turn? I'd rather try to avoid doing that. I don't believe we should start compiling random libraries against non-glibc libc implementations. I did a very simple and dumb check on the Portage tree and it looks like there are at least 4 other users of lrmi (zhcon, libx86, svgalib and read-edid), all of which are using their own, bundled version. I believe it would be better to try to fix those packages to use sys-libs/lrmi instead of compiling sys-libs/lrmi against klibc and making it usable for v86d only.
Created attachment 166222 [details] uvesafb module unable to handle kernel paging request Hello, I have a similar problem with uvesafb. It is unable to load v86d and returns a BUG message during the boot process. In my case the issue appears since it needs the v86d userspace helper. uvesafb is loaded as a module with the following options, options uvesafb mode_option=1400x1050-32@60 options uvesafb scroll=ywrap pmipal=1 nocrtc mtrr=3 blank I'm using klibc 1.5.12-r1, v86d 0.1.8 as specified on spock's site. The kernel is 2.6.27 vanilla. I will perform a new test with the debug flag.
(In reply to comment #49) > I have a similar problem with uvesafb. It is unable to load v86d and returns a > BUG message during the boot process. In my case the issue appears since it > needs the v86d userspace helper. uvesafb is loaded as a module with the > following options, > options uvesafb mode_option=1400x1050-32@60 > options uvesafb scroll=ywrap pmipal=1 nocrtc mtrr=3 blank Has uvesafb ever worked for you (any kernel and v86d versions)?
(In reply to comment #49 and comment #50) OK, I consider this particular issue to be closed as UPSTREAM (see http://bugzilla.kernel.org/show_bug.cgi?id=11661).
Closing as FIXED. Feel free to reopen if you're experiencing exactly the same issue as the one mentioned in the bug summary with: - latest available version of klibc, - latest available version of v86d. Otherwise, open a new bug.
