From owner-freebsd-hackers Sat Nov 8 01:58:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA27803 for hackers-outgoing; Sat, 8 Nov 1997 01:58:37 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (ppp13.portal.net.au [202.12.71.113]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA27792 for ; Sat, 8 Nov 1997 01:58:24 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id UAA00629; Sat, 8 Nov 1997 20:24:17 +1030 (CST) Message-Id: <199711080954.UAA00629@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Jonathan Mini cc: hackers@FreeBSD.ORG Subject: Re: x86 gods; advice? Suggestions? In-reply-to: Your message of "Sat, 08 Nov 1997 01:40:51 -0800." <19971108014051.33398@micron.mini.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 08 Nov 1997 20:24:16 +1030 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > Well. Te only thing I can think of is to set up a task gate that will > > > 'jump' you into a 32bit protected mode TSS, preferably the one where you > > > started. (I'm assuming the kernel's) > > > > This was suggested by another respondent. I'd be very interested in > > knowing how I could arrange such a thing, either overloading the > > existing syscall callgate or making another for temporary use (I have > > another free descriptor that I can hijack for the purpose). > > I don't know, I've never done it myself, personally. :) Ah. A handwave response. 8) I'll look at it tomorrow; it was suggested that I buy a book - obviously a suggestion from someone that doesn't live in this book-desert. > Ok, it is as I thought. Personally, I am a fan of the kernel keeping around > a few contexts that it rarely uses. Basically, IMHO, it would be best if once > the bootblocks got ahold of the system, they created three contexts : > - a 32-bit 'we are the kernel now' context, > - a 16-bit protected-mode 'let's play with the BIOS' context, and > - a 16-bit vm86 'let's pretend we are a Microsoft OS' context. Too complicated, and inadequate. There is a separate 32-bit context needed for the APM BIOS as well, and we are out of descriptors already. The vm86 support handles this differently by creating a kernel process at a later stage. > The idea is that the various contexts would be able to be used to 'pitch in' > when needed. For example, the boot process woudl change from hopping back and > forth from protected mode to real mode into : > > - hop into protected mode, create a vm86 task which handle > loading the kernel. (map the vm86 1M+ range to where you want the > kernel to go, or do a 1:1 map of all physical memory, and then set > the vm86's descriptor limit to 4G or so. Do all the loading from > vm86 mode. much easier code to look at) Unfortunately, we have no tools for writing realmode code. I was perhaps somewhat misleading regarding running the bootstrap in real mode; please look at the code for an understanding of the issues. > - hop into the kernel, from the vm86 task. The kernel would be in > a situation where it is in a ring 0 32bit TSS with a vm86 TSS which > has mappings to do some basic BIOS calls for it, possibly even some > complex ones. This isn't making a lot of sense to me. Are you implying that one could be in 32-bit PM and vm86 mode at the same time? > This means that there would be basically three parts to the kernel, a > main kernel which is as the kernel is now, and two stubs which reside in > vm86 and 16bit protected tss's. These stubs would be able to handle > various simple actions, such as running a bit of code and then exiting the > world via a call gate. (the effect would be similar to setting up a > timeout. Set the timeout, go out to lunch, and then get a function called > when the action is done) This is how the vm86 code works now. It's not usable for your projected scenario however as the timeout code doesn't happen until too late. > kernel, but the advantages would be _very_ nice. Unfortunatly, it would require > a multi-section kernel, and a compiler which groks 16bit code. This latter is a crucial issue. > > You've been able to run vm86 stuff in userland for ages; what is it that > > you are missing? Unless someone can identify any serious security > > holes in the implementation, vm86 support will stop being optional (at > > least for the APM case, I hope). > > A way which would allow the protected mode code to request services of > the vm86 code rather than visa versa. Currently, the only method I have > created is for the task to do a vfork, and the child turns itself into a > vm86 process with a monitor. What's the difference? Your execution passes between vm86 mode and 32-bit PM; which direction information passes is entirely a semantic issue. mike