Date: Fri, 7 Nov 1997 00:04:30 -0800 From: Jonathan Mini <mini@d198-232.uoregon.edu> To: Mike Smith <mike@smith.net.au> Cc: hackers@FreeBSD.ORG Subject: Re: x86 gods; advice? Suggestions? Message-ID: <19971107000430.02841@micron.mini.net> In-Reply-To: <199711070711.RAA01443@word.smith.net.au>; from Mike Smith on Fri, Nov 07, 1997 at 05:41:01PM %2B1030 References: <199711070711.RAA01443@word.smith.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
What privelege level is this running at? Why not just execute an illegal instruction and catch it? (in my vm86 code, I use hlt for this all the time) Mike Smith <mike@smith.net.au> stands accused of saying: > > Ok, I'm stumped. Short of someone responsible to shoot, I could do > with some help doing Evil x86 things. > > We all know why talking to the PnP BIOS would be a good thing. I don't > think there's any disagreement there. > > Actually doing it is being a little more challenging. The spec says > "It is assumed that the 16-Bit Protected Mode interface is sufficient > for 32-Bit Protected Mode operating systems". Maybe. > > To cut a long story short; it is necessary to construct three segments > (one 16-bit code, two 16-bit data), mapped as per the PnP connection > information. Done, no problem. > > You call into the 16-bit segment to a given entrypoint. Done, no > problem. > > The 16-bit segment wants to return to the caller. It executes an > 'lret', popping a 16-bit IP and CS off the stack. > > Oops. If you have the kernel CS there, you can return to any address > in the first 64k of the kernel segment. Unfortunately, that won't get > you anywhere near the kernel text. > > As an alternative, I tried stealing a spare segment and arranging that to > be based at the bottom of the kernel, so that the return would be into > kernel text space, then pushing the kernel CS and IP of a suitable > label onto the stack and lret'ing again to get back into the kernel. > > *this* tries to access memory at vaddr 0x81: > > /* biospnp(int offset, int segment, int junk, u_int16_t args[...]) */ > > ENTRY(biospnp) > popl %ecx /* save return address */ > > movl %pnpret,%bx /* local return point */ > mov %bx,(2*4)(%esp) > > lret > > pnpret: pushl $8 > pushl %ecx > lret > > The high half of (junk) comes in with the prepared selector for return > in it. This *works* until the pnpret: label. Unfortunately, at that > point it's not (yet) running on the kernel text selector, so ddb can't > actually tell me what's going on. The stack looks OK (I never touch > it), so I am somewhat stuffed as to what is going wrong. > > Any ideas? Any better ways of getting back into the kernel from 16-bit > mode? > > mike -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971107000430.02841>