Re: having System.map reflect the running kernel

Todd Fries (tfries@umr.edu)
Tue, 5 Sep 1995 22:38:04 +0000 (GMT)

This is exactly the behavior that IS documented in the 'Intel Secrets'
web site, which documents and fully explains this and other 'chipset-dependent'
secrets, or if you rather, undocumented features.

I don't pretend to know fully what is going on, so I'll just point you to the
url and let you guys find out for yourselves.

http://x86.metronet.com/undoc

> Snow Cat: "Re: having System.map reflect the running kernel" (Sep 4, 10:08):
> >
> > Why so complicated? :) Just go to protected mode, set ds,es,fs and gs to
> > segments with 4GB limit and then go to real mode without reloading them
> > with 64K segments. Then one can accesss all 4GB in memory (for example
> > xor ax,ax; mov ds,ax; mov eax,[0x10000000H]) AND make 16 bit BIOS calls.
>
> Is this guaranteed to work? I suspect it will break on many machines
> where the BIOS does a save/restore of the segment register and the
> restore will make the segment be truncated back to a 16-bit one (holds
> especially for interrupts etc).
>
> (it may well be that most processors won't change the "limit" of the
> segment cache when re-loading a real-mode segment, but quite frankly,
> this is not documented behaviour as far as I know, and I wouldn't be
> surprised if it didn't work on clones and/or P6 chips etc).
>
> The %fs/%gs segments might be reasonably safe, but I suspect modern
> BIOSes will use even those segments internally.
>
> Linus

-- 
Todd Fries...tfries@umr.edu
http://www.cs.umr.edu/~tfries