From owner-freebsd-hackers Fri Nov 7 00:05:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA17350 for hackers-outgoing; Fri, 7 Nov 1997 00:05:30 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from d198-232.uoregon.edu (d198-232.uoregon.edu [128.223.198.232]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA17345 for ; Fri, 7 Nov 1997 00:05:26 -0800 (PST) (envelope-from mini@d198-232.uoregon.edu) Received: (from mini@localhost) by d198-232.uoregon.edu (8.8.5/8.8.5) id AAA17422; Fri, 7 Nov 1997 00:04:30 -0800 (PST) Message-ID: <19971107000430.02841@micron.mini.net> Date: Fri, 7 Nov 1997 00:04:30 -0800 From: Jonathan Mini To: Mike Smith Cc: hackers@FreeBSD.ORG Subject: Re: x86 gods; advice? Suggestions? References: <199711070711.RAA01443@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <199711070711.RAA01443@word.smith.net.au>; from Mike Smith on Fri, Nov 07, 1997 at 05:41:01PM +1030 X-files: The Truth is Out There Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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 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."