Sender: nate AT cartsys DOT com
Message-ID: <36E47DA4.D9E2374B@cartsys.com>
Date: Mon, 08 Mar 1999 17:47:16 -0800
From: Nate Eldredge <nate AT cartsys DOT com>
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.1 i586)
MIME-Version: 1.0
To: djgpp AT delorie DOT com
Subject: Re: Getting cr2 in exception handler
References: <36E1D56E DOT ABB127DE AT cartsys DOT com> <36e3eacd DOT sandmann AT clio DOT rice DOT edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp AT delorie DOT com

Charles Sandmann wrote:

> > So: Does anyone know of another way to find the value of cr2?  I don't
> > care about it working in anything but CWSDPMI.
> 
> There are some tricks that can probably be done to get the value:
> 
> 1) Pull it out of the memory data structure using some tricks to find it.
> 2) Set up a ring-0 call gate and point it to some routine in your code.
>    This is a hole in the CWSDPMI ring-3 security on purpose to allow
>    such things.  You will need to have an Intel reference manual and
>    probably the CWSDPMI source to know what needs to be done, however.

Actually, I realized another problem with such an approach.  If I get it
from anywhere besides the exception handler stack (as not supported by
CWSDPMI), another page fault may have occurred since then, i.e. in
swapping in my signal handler.  Since [deity of your choice] only knows
what memory that might touch, I doubt I can hope to lock it selectively,
which means I must lock everything.  Avoiding that was my major reason
not to use CWSDPR0, but I guess I can't avoid it anyway.  Only users
with money for RAM get to use that feature, I guess. :)

It shouldn't be all that dangerous to run in ring 0 anyway. 
Segmentation and paging still apply (with the exception of read-only
pages on i386, which I never use anyway).  The only trouble will be that
if data starts being executed, privileged instructions could come up and
mess up the system (mov cr0, reg), but at IOPL 0 there's plenty of room
for users to shoot themselves in the foot executing data in any case...
;-)
-- 

Nate Eldredge
nate AT cartsys DOT com