Date: Sat, 8 Nov 1997 01:40:51 -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: <19971108014051.33398@micron.mini.net> In-Reply-To: <199711080855.TAA00364@word.smith.net.au>; from Mike Smith on Sat, Nov 08, 1997 at 07:25:04PM %2B1030 References: <19971107192715.29070@micron.mini.net> <199711080855.TAA00364@word.smith.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith <mike@smith.net.au> stands accused of saying: > > > > Personally, I feel very insecure running a BIOS at DPL = 0. I certainly > > > > woulndn't like letting third party software muck with everything. (even if it > > > > is on a ROM (ok, a flashable ROM)) > > > > > > Like I said, if you have a better idea, I am seriously interested in > > > pursuing it. > > > > 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. :) > > When is this code being run? Are we talkign about a during-boot-cycle type > > setup, or is the scheduler online and tickign away at this point in time? > > Both. The initial PnP calls have to be made very early, in order to > ascertain system resource availability. Then later a pass can be made > to pick up peripheral details. 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. 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) - 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. - create the 16-bit protected-mode tss now. Use this to collect PnP BIOS information, or whatever. Possibly even use the vm86 BIOS to reset your hardware. (I did this as a first attempt at making vm86 do hardware control. It was fun to watch syscons dissapear as the videocard's BIOS reset itself and the Trident BIOS logo appear. (My crash machine has an old 16bit ISA Trident VGA cards that is slow, but works)) 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) What would be best would be to extend the current SYSINIT system to give the type of TSS wanted while the action takes place. For example, the the PnP code would be one entry inf the SYSINIT table, which would be followed by another entry which would use the info that probe created, etc, etc. I'm certain how much of a restructure this would require in the FreeBSD kernel, but the advantages would be _very_ nice. Unfortunatly, it would require a multi-section kernel, and a compiler which groks 16bit code. > > > It's not entirely elegant, or even mostly mine, but there's a single-line > > > call you can make anywhere (once its safe to sleep) inside the kernel that > > > will run a vm86-mode interrupt for you. > > > > Hmm. I'. not using kernel code for this. (it's all userland) > > 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. (I am working on a VESA VBE 1.2 & 2.0 graphics library, which John-Mark Gurney (a friend on mine) has said that there would be interest for from FreeBSD, so perhaps my private project isn't so private.) > > 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?19971108014051.33398>