Conference noted::hackers_v1

    If you want to get a shareable image without mapping the global
    section, just put some universal symbol in it, link to it, and install
    it /SHARE/WRITE. That should do it. 
    
    No, you can't delete the VA and have some other process detect it. Your
    VA is your VA. I doubt you can change page protection across processes,
    either. You can in system space, of course, but that's different.
    
    	Jon

    The particular psect that you wish to share must also have the SHR
    attribute, else each image will get its own copy.  Many times, writable
    psects will not have this attribute, since you most commonly want
    the writable parts to be impure private sections.  BTW, Fortran
    gives COMMON psects WRT,SHR, as I found out once to my great grief
    when trying to make a sharable image out of a Fortran program.
    
    Burns

    Hopefully, Burns discovered and used the PSECT= command in a Linker
    options file to curb his grief.

    I did.
    
    Actually, it was kind of amusing to watch one processes jerk each
    other around.  Users would not have liked it, however.
    
    Burns
    

    Re: 0
    
    When the system defines your virtual address space, it creates for
    you a table with, amoung other things, gives you the page protection
    and the physical page of memory to use.   Two processes can share
    the same page by making the physical page pointer point to the
    same place, but two process can't share the same page protection
    table.   

    	KC

    I don't need to really share the same page protection.
    
    It would be sufficient if it were possible for one of the two
    processes to delete a page so the other process suddenly gets
    an access violation on that page, even though it DIDN'T get one
    a few seconds ago.
    
    Is there a way to do this ?
    
    /Eric

    Re: Changing the protection
    
    It is fairly simple in concept.   Send a special kernel AST to the
    process you are interested in and in the context of that process
    do a $DELTVA of $SETPRT or whatever.
    
    Debugging it might be a bit tedious.  
    
    	KC

Re .7:

Instead of KAST to tell the process to do the $DELTVA, would you expect
that the process itself could do the $DELTVA itself in user mode ?
Would other process then experience access violations on the page ?

/Eric

1. Change_mode_to_kernel, and raise IPL to SYNCH,
2. Find the other process's page-table in system-space, using that
   process's POBR or P1BR from its PCB,
3. Poke the appropriate PTE for the page,
4. Lower IPL and RET.

   There's no need to TBIS the page, because the other process isn't
   running...you are.

P.S. This doesn't work on a multiprocessor VAX.

Ron

The previous reply is useful only if you wish to set the protection on a
page in another process's P0 or P1 space...you have to do other things to
actually DELETE the page.

Cheers,

Ron

    If you're going to change page protection, you *must* invalidate the
    translation buffer! You have no idea what sort of funny interrupt is
    going to come in and screw things up. I know it's strictly not needed,
    but not doing it is leaving yourself open for subtle bugs that are
    *very* hard to debug. It's always safer to follow ritual. 
    
    You can invalidate the translation buffer in Macro with the instruction: 
    
    	MTPR	#0,PR$_TBIA
    
    In Bliss, this block will do it:
    
    	BEGIN
    	BUILTIN MTPR;
    	MTPR( %ref(0), PR$_TBIA );
    	END;

    		Jon

    Re: .9
   
    I was thinking that it would be more 'interesting' to change
    the page protection myself,  but most people cringe at the
    thought.   Of course, this is for hackers ...   Although it
    is probably easier to debug that my suggestion.
    
    re: .8
    
    The $DELTVA needs to be executed in the context of the process
    that is supposed to get the accvio.   You can deliver a
    special kernel AST to execute some code in that processes
    context, but you can't just execute the service on behalf
    of that process.
    
    	KC

    This kernel stuff just won't do.  You'll know why when I explain
    my original motivation.
    
    I was reading some VMS source code, and I noticed that lots of system
    services do a PROBER or PROBEW before referring to some parameter
    by reference.  Such a check avoids a system crash which would occur
    if a bad reference were made.
    
    So I got to wondering if there were a potential bug in those sorts
    of places.  The bug would be:  What if the PROBER says the parameter
    is readable, and then right after that the parameter becomes
    unreadable, and then right after that the code goes to read the
    parameter.  Whamo!  System would crash.
    
    So I was thinking about if the scenario were possible.  I considered
    using spawn/nowait to create a program that repetively executes a system
    service, and then simultaneously running a program in top process
    that repetively makes the parameter page be existent and nonexistent,
    or readable and nonreadable.
    
    Statistically, before too long, the above dovetailing ought to be
    observed and the system crash.
    
    The clincher so far though is that I can't figure out a way to
    allow the two processes to have access to the same page, enough
    access so that one can delete or change the page's protection so
    that the other process sees the change.
    
    Perhaps it's impossible, which merely means the suspected bug
    doesn't exist.
    
    Since I'm looking for a vms bug, kernel mode methods won't do,
    since I'm trying to demonstrate a bug in non-priveleged user
    environments.
    
    Anyone have any ideas ?  Do you think the bug might really exist?
    
    By the way, I was considering doing the experiment with just ONE
    process, which loops doing the system service, while it uses a
    repetive timer AST to flip the accessibility of the page.  However,
    I assume this won't work, since the user-mode AST I presume will
    never succeed in interrupting the system service code, since that
    code is running in kernel mode.
    
    /Eric

    As I understand it, you're looking for potential bugs in ASYNCHRONOUS
    kernel-mode system services that might not be copying their parameters
    before the first caller-mode stall point.
    
    Why don't you just call the no-wait version of the system service
    from user mode, and then (after the service returns, but before
    it completes) $DELTVA the page containing the parameters and the
    original service call's argument list (which must be built in VM,
    not on the stack).
    
    Statistically, you are bound to find any problems, since the first
    user-mode stall should give you enough time to unmap the relevant
    pages before the kernel-mode thread resumes at AST level.
    
    Note that unmapping I/O buffers used on $QIOs may fail, since I
    believe that these pages become locked into physical memory
    (for DMA transfers).
    
    Note also that you won't be catching the more subtle (and insidious)
    bugs - for example, at the start of the system service, relevant
    PCB privilege bits need to be copied to the kernel-mode request
    context block.
    
    As far as your original statement "What if the PROBER says the
    parameter is readable, and then right after that the parameter
    becomes unreadable...", this doesn't really make sense for
    SYNCHRONOUS system services (or for properly written ASYNCH ones),
    since it is OK to assume that after a kernel-mode PROBE, the
    mapping context of the probed page will not change until the
    service returns to the mode of the caller for the first time.
    (Otherwise, it would be impossible and pointless to PROBE the
    service arguments in the first place.)
    
    -steve-

>    `    becomes unreadable...", this doesn't really make sense for
>    SYNCHRONOUS system services (or for properly written ASYNCH ones),
>    since it is OK to assume that after a kernel-mode PROBE, the
>    mapping context of the probed page will not change until the
>    service returns to the mode of the caller for the first time.
>    (Otherwise, it would be impossible and pointless to PROBE the
>    service arguments in the first place.)
    
    	A "change in mapping context of the probed page for SYNCHRONOUS
    	system services" is EXACTLY what I am looking for !
    
    	I'm wondering if by having the page be part of a shared section,
    	one process could alter the mapping context out from under the
    	other process which is doing the "synchronous" service.
    
    	/Eric

    But how, in reality, do you expect the protection of a probed page
    to change during the execution of a synchronous kernel-mode system
    service?  I think it is a fundamental assumption that can be made
    within any single process that when you're executing in kernel mode
    (synchronously) that nothing else can mess with your virtual page
    table in such a way that it would affect the accessibility of a
    page.  The only exceptions would be other kernel-mode routines
    that are called by the executing system service (or by a kernel-mode
    AST routine).  After all, you "own" control of the process at that
    point.
    
    I suppose you could establish a timer-based kernel-mode AST thread
    that unmapped certain virtual pages, but if you find any bugs with
    that, they wouldn't necessarily be "real" bugs, since this isn't
    really allowed (unprivileged code could never do it).
    
    I guess I still don't understand what you're really trying to test.
    
    -steve-

    I understand that while a kernel-mode synchronous system service
    is executing, no lesser access mode AST routine IN THE SAME PROCESS
    can intervene.
    
    However, it's my understanding that lesser mode code of OTHER PROCESSES
    may very likely intervene due to scheduler's whims.
    
    So, suppose two processes have the same section mapped into memory.
    I'm wondering if one process can delete or change the protection
    of some portion of the section's pages, such that the other process
    (which is in kernel mode) is affected by the change.
    
    Here's my idea, time flows DOWN the page, two columns representing
    events in process A and B:
    
    Process A does this			Process B does this
    -------------------			-------------------
    Creates and maps a section
    					Maps same section so it's now
    					shared
    Starts system service
    
    Kernel-mode system service verifies
    accessibility of passed-by-ref
    parameter
    					Alters section or page protection
    					such that parameter is no longer
    					accessible
    Attempts to reference the parameter
    
    
    ----------------------------------------------------------------------
    Is it more clear now ?
    
    /Eric

    You have Page Table Entries for Global Sections in your Process
    Page Table.  These are special copies of the System Global Section
    Page Entries that exist in System Space, but they are wholely within
    your Process Private Context.  As such any (valid, legal, normal)
    attempt by anyone else to modify the systems references of a Global
    Section, merely result in the system decrementing/incrementing a
    reference counter.  If the reference counter ever reaches zero,
    and it sees that someone tried to delete it, then and only then,
    the system will actually delete the section.
    
    The system (and any individual) does not actualy know who has mapped
    a global section, and thus has private page table entries pointing
    to the shared section.  Therefore if it (or anyone) actually did remove
    it before then, all the remaining processes still mapped to it would
    be pointing to an undefined data area.  They (and probably the system)
    will soon die.
    
    Please note that a determined Kernel-Mode hacker COULD actually
    do this by find the address of the Global Section Descriptor in
    System Space, and overwriting it (kernel mode write).  This will
    probably (99%) cause the system to bugcheck, no matter what other
    users who are mapped to it are doing.
    
    -- Barry
     

    re ;18
    
    I agree completely.  In short, there is NO WAY that your virtual
    address space configuration (page table) can be changed by another
    process unless that process intentionally chases down your page
    table and mungs it.  There is no system service that does this,
    and if there ever was one, it would break most of VMS.
    
    -steve-

    In .17, Osman is describing a different scenario for 'cracking'
    the system.  Inner mode system services should validate the
    user-passed parameters every time their used, unless a local
    copy of them is made.  The easiest way to find such a chink in
    the system is by reading the sources.

>    Inner mode system services should validate the
>    user-passed parameters every time their used, unless a local
>    copy of them is made.
    
    From what we've said so far, this sounds either insufficient OR
    unnecessary.
    
    If in fact there is NO way for a normal process to alter
    the accessibility of another process's map, then there's no
    need to revalidate, since the accessibility can't have changed.
    
    On the other hand, if it IS possible, then validation isn't
    sufficient, since the alteration might happen between the
    validation and the actual reference.
    
    This latter problem could be solved by turning off scheduling
    during the validation/reference segment, but if THAT'S needed,
    there are literally thousands of places in the current VMS
    that are lacking the appropriate complexity.
    
    /Eric

    I think the real rule is that caller-supplied parameter values
    MUST be copied into kernel mode (after PROBER) if they will be
    referenced more than once during the system service (even if
    the service is synchronous).  This is because the parameters may
    be in a global section, the *contents* of which may be changed
    by another process during the execution of the system service.
    
    Therefore, it is the *values* of the parameters that can be changed
    during the synchronous service, not the *accessibility*.
    
    Also, output parameters must be *write-only*, since the service
    can't trust the value to stay where it was written (since that
    too might be a global section).
    
    For *asynchronous* services, all parameters that will be needed
    during secondary processing steps must be PROBERed and copied to
    kernel mode during the service's first-part.  Then, *all* references
    to these parameters must be through the kernel-mode copies.
    
    Output parameters must be PROBEWed at least once during *each*
    processing step that actually writes them, since accessibility
    of these pages *can* change during caller-mode stalls.
    
    Are we getting close to consensus on this yet?
    
    -steve-

For "copied to kernel mode", fetching the parameter into a register suffices.