From:	MERC::"uunet!WKUVX1.BITNET!MacroMan" 18-MAR-1993 09:04:23.36
To:	MACRO32 <MACRO32@WKUVX1.BITNET>
CC:	
Subj:	Re: Sys. Serv. Hook (Was RE: Imp terminates Qio !)

>I'm not sure that's necessary.  On the rare occasions where system

Yeah! When it's well behaved VMS code/ASTs, etc.  It's the 'foreign' (NOT
supplied with VMS) code that I was concerned with.

>services call other system services, they call the EXE$xxx entry points,
>since the main purpose of the system service vectors is to provide an
>entry point for outer access mode callers to come in thru a change mode
>handler to run inner mode code.  An AST delivered from somewhere else is
>going to already be in an inner mode and not need to go through the
>change mode handler.

Oh Yeah! And how to you propose the AST will find these EXE$xxx points of
the system services?  (eg: EXE$QIO)  Actually, EXE$QIO is the S0 table
vector.  It contains the same MASK, CHMK #<?> and RET as the P1 SYS$QIO.
Hence, you will still be going thru the Change mode dispatch! The actual
QIO routine (dispatched by EXE$CMODKRNL)  is loaded _somewhere_ in S0
space.  Try finding it! It AIN'T easy.

1) EXE$CMODKRNL (EXE$CMODEXEC) aren't fixed in S0. They're loadable images
   and can NOT be guaranteed to be in the same location from boot to boot.
   However, you can locate them from SCB+40(16) and SCB+44(16).

2) The entry points of the service routines are located in the change mode
   dispatch tables pointed to by CMOD$AR_<mode>_DISPATCH_VECTOR.  Here's
   another one for you to track down!

3) IF you know the Loadable Exec. Image that the routine is found in, you
   CAN find its loaded address by walking the LDRIMG blocks.  Then, IF you
   know IMAGE VALUE of the routine, you CAN calculated the loaded address
   of its entry point.  AND... How do you get the IMAGE VALUE?  Still more
   gyrations...

A lot of work to directly call the service routine directly, especially if
you're in an AST!

Brevity here.  On account of I have a train-stopping headache this morn.

>One thing that pulls the same grubby trick is DEBUG, and doesn't bother
>raising IPL or locking the vectors down after creating the new vector.
>Note also that DEBUG remaps the _whole_ vector table, not just parts of
>it.  It's done by copying the vector table into a local save area and
>restoring it after the $CRETVA.  The page protection is left at URKW.

AHHHH... You let the cat outta the bag.

>Also, the $DELTVA call is superfluous, since $CRETVA always discards the
>pages that are being remapped.

I wanted to break down the steps of remapping the table vector so that it
was more apparent what was actually happenin'.
---
Actually, I'm surprised that a cut-and-paste faux pax in a pseudoSDA output
(used to comment the code) went 'unpunished'!  I specified one PFN in the
EVAL/PFN command but displayed (formatted) another.  Oops!  It should also
have L under the bits field since it is now locked in the working set.
---
The real challenge of that ditty was to devise a mechanism to execute the
"set prompt" code in exec mode and keep the functions of the hook routine
process specific.  The WRTATTN AST on the mailbox worked out real nice.

Got any other ideas on how to do it?  It may prove to be a bit more
interesting than the discussion ensuing about RMSing with the UAF!

BJS- /Brian Schenkenberger/Schenkenberg@Eisner.DECUS.Org/Space for Rent/
    /VMS Software Support/Vitronics, Inc./Eatontown, NJ/(908) 542-0600/
   /Independent Consult./Tmesis Consulting/Jackson, NJ/(908) 363-7551/
  /<VAXman or Schenkenberger>@Monmouth-ETDL1.Army.Mil/CIS: 70253,114/