Date: Sat, 08 Nov 1997 20:24:16 +1030 From: Mike Smith <mike@smith.net.au> To: Jonathan Mini <mini@d198-232.uoregon.edu> Cc: hackers@FreeBSD.ORG Subject: Re: x86 gods; advice? Suggestions? Message-ID: <199711080954.UAA00629@word.smith.net.au> In-Reply-To: Your message of "Sat, 08 Nov 1997 01:40:51 -0800." <19971108014051.33398@micron.mini.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711080954.UAA00629>