From:	AITGW::"MACRO32@WKUVX1.BITNET" 22-FEB-1992 16:34:10.36
To:	MACRO32%WKUVX1.BITNET@TGV.COM
CC:	
Subj:	Re:  Bug in IOC$SEARCHDEV??!!!??

Received: by AITGW.DECnet (utk-mail11 v1.5) ; Sat, 22 Feb 92 16:31:24 EST
Received: from ukcc.uky.edu by aitgw.ge.com (5.65/GE Gateway 1.4)
	id AA15180; Sat, 22 Feb 92 16:31:07 -0500
Received: from ukcc.uky.edu by UKCC.uky.edu (IBM VM SMTP V2R2)
   with BSMTP id 0718; Sat, 22 Feb 92 16:26:41 EST
Received: from UKCC by ukcc.uky.edu (Mailer R2.08) with BSMTP id 9553; Sat, 22
 Feb 92 16:26:14 EST
Received: from WKUVX1.BITNET by ukcc.uky.edu (Mailer R2.08) with BSMTP id 9467;
 Sat, 22 Feb 92 16:25:19 EST
Errors-To: MacroMan@WKUVX1.BITNET
X-Listname: "VMS Internals, MACRO, and BLISS Discussions"
    <MACRO32@WKUVX1.BITNET>
Received: from CUNYVM.BITNET (MAILER) by WKUVX1 (MX V3.0A) with BSMTP; Sat, 22
          Feb 1992 15:25:37 EST
Received: from CUNYVM by CUNYVM.BITNET (Mailer R2.08) with BSMTP id 7764; Sat,
          22 Feb 92 16:16:16 EST
Received: from TGV.COM by CUNYVM.CUNY.EDU (IBM VM SMTP V2R2) with TCP; Sat, 22
          Feb 92 16:16:15 EST
Date: Sat, 22 Feb 1992 13:16:23 -0800 (PST)
From: <MILLER@TGV.COM>
Reply-To: MACRO32@WKUVX1.BITNET
Subject: Re:  Bug in IOC$SEARCHDEV??!!!??
To: MACRO32%WKUVX1.BITNET@TGV.COM
Message-Id: <698793383.326013.MILLER@TGV.COM>
In-Reply-To:  <920222032838.6c@VESTA.SUNQUEST.COM>
Mail-System-Version: <VAX-MM(298)+TOPSLIB(154)@TGV.COM>
 
>        HOWEVER, in writing some test code, I discovered that
>        IOC$SEARCHDEV uses the IFNORD macro to determine if it
>        can access the device name descriptor; this means that
>        the descriptor *must* be stored in a location accessible
>        to the previous processor mode!  In other words, what I
>        was trying to do (build a descriptor on the kernel stack
>        and then send (sp) through) would not work, *unless* I
>        jumped into kernel again... (sample code below sig)
>
>        Should I SPR this or did I goof?
 
It's not a bug.  It's just the way things work, in my opinion.
Anyway you slice it, the routine, in most cases, has to check
access against the previous mode.  Otherwise anyone could write
a program to examine any location in the kernel.
 
I ran into this problem when I was writing a driver that acted
as a front end to another driver.  I wanted to put a descriptor
on the kernel stack and call IOC$SEARCHDEV.  There are two, sorry,
three work-arounds.  You can do another $CMKRNL, but takes too much
overhead and it's not safe in certain situations.  You could search
the device list yourself, but that's a pain and it's too easy to
screw-up, especially with new releases of VMS.  The solution I
prefer goes something like this:
 
        movpsl  -(sp)
        pushal  10$
        movpsl  -(SP)
        insv    <kernel_mode>,(SP)      ; change mode field on stack
        pushal  5$
        REI
5$:     ; call IOC$SEARCHDEV
        REI
10$:
 
That's pseudo-code since I'm at home and I don't have any examples
handy and besides, it's a nice sunny Saturday here in Santa Cruz and
I shouldn't even be reading mail right now.  I think I got the code
right, but...
 
NB: If you are not the only agent passing parameters to IOC$SEARCHDEV,
you much check the access for any other buffers in the previous access
mode.
 
-bruce
 
----------------------------------------------------------------------------
Bruce R'. Miller, MILLER@TGV.COM        (408) 427-4366  in Santa Cruz CA
        "And through the wire, we can talk..." - PG
