Addressing MVS control blocks from Hercules e.g. PSAAOLD/PSATOLD

[michealbutz2002]

Hi

 is it possible to address MVS control blocks from Hercules in ESA390.H

There are 2 definations for the PSA PSA_3XXX and PSA_390 when I add to
either on at offset hex 210/224 psatold/psaaold and try to view it via
MS Visual Studio debugger I get garbage  

 Can I do this ???

[Binyamin Dissen]

On Sun, 17 Aug 2008 20:39:09 -0000 "michealbutz2002"
<bytemaster@...> wrote:

:> is it possible to address MVS control blocks from Hercules in ESA390.H

:>There are 2 definations for the PSA PSA_3XXX and PSA_390 when I add to
:>either on at offset hex 210/224 psatold/psaaold and try to view it via
:>MS Visual Studio debugger I get garbage  

:> Can I do this ???

Most such values are virtual, which means that you need to apply DAT to
calculate the real addresses.

Try going to the address off of the program new PSW which should be real.

--
Binyamin Dissen <bdissen@...>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

[michealbutz2002]

--- In hercules-390@..., Binyamin Dissen <bdissen@...>
wrote:
>
> On Sun, 17 Aug 2008 20:39:09 -0000 "michealbutz2002"
> <bytemaster@...> wrote:
>
> :> is it possible to address MVS control blocks from Hercules in
ESA390.H
>
> :>There are 2 definations for the PSA PSA_3XXX and PSA_390 when I
add to
> :>either on at offset hex 210/224 psatold/psaaold and try to view
it via
> :>MS Visual Studio debugger I get garbage  
>
> :> Can I do this ???
>
> Most such values are virtual, which means that you need to apply
DAT to
> calculate the real addresses.
>
> Try going to the address off of the program new PSW which should be
real.

>
> --
> Binyamin Dissen <bdissen@...>
> http://www.dissensoftware.com
>
> Director, Dissen Software, Bar & Grill - Israel
>
>
> Should you use the mailblocks package and expect a response from me,
> you should preauthorize the dissensoftware.com domain.
>
> I very rarely bother responding to challenge/response systems,
> especially those from irresponsible companies.
>

 Since this is a private address space the PSW wont help

I think there maybe a module dat.x that I can get the virtual address
for

[somitcw]

--- In hercules-390@...,
 "michealbutz2002" <bytemaster@...> wrote:
> Hi
> is it possible to address MVS control blocks
>from Hercules in ESA390.H
> There are 2 definations for the PSA PSA_3XXX and
>PSA_390 when I add to either on at offset hex
>210/224 psatold/psaaold and try to view it via
>MS Visual Studio debugger I get garbage  
> Can I do this ???

   Are you looking at the Prefix Storage Area real,
virtual, or absolute address?

   What commands are you using?

   What responses did you get?

   What does the Prefix Register for each CPU
point to?

[michealbutz2002]

I am trying to look at a private address space from whitin  Hercules
so I need to know what address space I am dealing with

A picture is worth a thousand word so I'll show you snipets of my code
in ESA390.H

typedef struct ASCB_a                 <--- MY CODE
{
char fillerc[36];                     <-- MY CODE  
/* asid of address space */ HWORD ascbasid;    <-- MY CODE
} ASCB;                             <-- MY CODE

typedef struct ASCB_a *PSAAOLD;    <-- MY CODE


/*1C0*/ FWORD  storecr[16];             /* Control register save area*/
BYTE resv0201[28];
/* current dispatched TCB  21C */ FWORD psatold; <-- MY CODE
BYTE resv0202[4];
 /* HOME ADDRESS SPACE */ PSAAOLD psaaold; <-- MY CODE
} PSA_3XX;

/*01F0*/ QWORD  iopnew;                 /* I/O new PSW               */
/* 0200 */  BYTE   resv0200[4096];         /* Reserved                  */
BYTE resv0201[28];
/* current dispatched TCB  21C */ FWORD psatold; <-- MY CODE
BYTE resv0202[4];
 /* HOME ADDRESS SPACE */ PSAAOLD psaaold;   <-- MY CODE
 BYTE resv0203[4056];
/*1200*/ FWORD  storefpr[32];           /* FP register save area     */
/*1280*/ DBLWRD storegpr[16];           /* General register save area*/
/*1300*/ QWORD  storepsw;               /* Store status PSW save area*/
/*1310*/ DBLWRD resv1310;               /* Reserved                  */
/*1318*/ FWORD  storepfx;               /* Prefix register save area */
/*131C*/ FWORD  storefpc;               /* FP control save area      */
/*1320*/ FWORD  resv1320;               /* Reserved                  */
/*1324*/ FWORD  storetpr;               /* TOD prog reg save area    */
/*1328*/ DBLWRD storeptmr;              /* CPU timer save area       */
/*1330*/ DBLWRD storeclkc;              /* Clock comparator save area*/
/*1338*/ DBLWRD resv1338;               /* Reserved                  */
/*1340*/ FWORD  storear[16];            /* Access register save area */
/*1380*/ DBLWRD storecr[16];            /* Control register save area*/
} PSA_900;





 In cpu.c

psa = (void*)(regs->mainstor + regs->PX);
myasid = ((U16) *psa->psaaold->ascbasid


 I am running this code under the Visual Studio debugger
when I reference myasid I blow up  



--- In hercules-390@..., "somitcw" <somitcw@...> wrote:

>
> --- In hercules-390@...,
>  "michealbutz2002" <bytemaster@> wrote:
> > Hi
> > is it possible to address MVS control blocks
> >from Hercules in ESA390.H
> > There are 2 definations for the PSA PSA_3XXX and
> >PSA_390 when I add to either on at offset hex
> >210/224 psatold/psaaold and try to view it via
> >MS Visual Studio debugger I get garbage  
> > Can I do this ???
>
>    Are you looking at the Prefix Storage Area real,
> virtual, or absolute address?
>
>    What commands are you using?
>
>    What responses did you get?
>
>    What does the Prefix Register for each CPU
> point to?
>

[kerravon86]

--- In hercules-390@..., "michealbutz2002" <bytemaster@...>
wrote:
>
> /* asid of address space */ HWORD ascbasid;    <-- MY CODE

> psa = (void*)(regs->mainstor + regs->PX);
> myasid = ((U16) *psa->psaaold->ascbasid
>
>  I am running this code under the Visual Studio debugger
> when I reference myasid I blow up  

Sure that shouldn't be psa->etc instead of *psa->etc?
Looks to me like you're making a hword into a pointer
when it shouldn't be???

BFN.  Paul.

[Roger Bowler]

--- In hercules-390@..., michealbutz2002 wrote:
>  In cpu.c
> psa = (void*)(regs->mainstor + regs->PX);
> myasid = ((U16) *psa->psaaold->ascbasid
>  I am running this code under the Visual Studio debugger
> when I reference myasid I blow up  

You need to keep a clear distinction in your mind between pointers
that point into Intel storage and pointers that point into S/390
storage. You cannot mix the two. Another thing you need to take into
account is that mainstor is real storage and psaaold is a virtual
address pointing into common storage (E)SQA.

psa->psaaold->ascbasid is mixing up three different addressing
concepts and will almost certainly segfault.

Just to complicate matters further, Intel pointers are
"back-to-front", so for example 12345678 is stored in Intel storage as
78563412 (I gave up wondering why about 10 years ago :-))

The correct way to do it would be something like this:
- calculate the address of the PSA in mainstor
- use FETCH_FW to load the fullword at psaaold
- perform virt_to_abs translation to get address of ASCB in mainstor
- use FETCH_HW to load the halfword from ASCBASID

You must also deal with things like translation exceptions, addressing
exceptions, and crossing page boundaries (i.e. you cannot just add the
offset of the ASCBASID field to the starting address of the ASCB
unless you are sure that the ASCB does not cross a page boundary).

Give us a hint what you are trying to achieve. We might be able to
suggest another method.

Regards,
Roger Bowler
Hercules "the people's mainframe"

[michealbutz2002]

I am a an Assembler internals Guy and am trying to expand my
horizons  

I am trying to display MVS info e.g. some of the things in HSCCMD.C

In a GUI front I did a Windows API CreateProcess to Create a Window
32 WinMain app to display info displayed in DOS box from hsccmd.c


you have given me some idea of what I need to do

let me see if this can help

      thnakx


--- In hercules-390@..., "Roger Bowler"
<rogerbowler@...> wrote:

>
> --- In hercules-390@..., michealbutz2002 wrote:
> >  In cpu.c
> > psa = (void*)(regs->mainstor + regs->PX);
> > myasid = ((U16) *psa->psaaold->ascbasid
> >  I am running this code under the Visual Studio debugger
> > when I reference myasid I blow up  
>
> You need to keep a clear distinction in your mind between pointers
> that point into Intel storage and pointers that point into S/390
> storage. You cannot mix the two. Another thing you need to take

into
> account is that mainstor is real storage and psaaold is a virtual
> address pointing into common storage (E)SQA.
>
> psa->psaaold->ascbasid is mixing up three different addressing
> concepts and will almost certainly segfault.
>
> Just to complicate matters further, Intel pointers are
> "back-to-front", so for example 12345678 is stored in Intel
storage as
> 78563412 (I gave up wondering why about 10 years ago :-))
>
> The correct way to do it would be something like this:
> - calculate the address of the PSA in mainstor
> - use FETCH_FW to load the fullword at psaaold
> - perform virt_to_abs translation to get address of ASCB in
mainstor
> - use FETCH_HW to load the halfword from ASCBASID
>
> You must also deal with things like translation exceptions,
addressing
> exceptions, and crossing page boundaries (i.e. you cannot just add
the

> offset of the ASCBASID field to the starting address of the ASCB
> unless you are sure that the ASCB does not cross a page boundary).
>
> Give us a hint what you are trying to achieve. We might be able to
> suggest another method.
>
> Regards,
> Roger Bowler
> Hercules "the people's mainframe"
>

[Mike Schwab]

Back in the 8080 8-bit days, the processor would
Byte 1: read the 78 of two numbers, add them, store into the result,
increment the address,
Byte 2: read the 56 of the two numbers, add them including the
overflow from the previous byte, store  the result,
Byte N: and repeat through the rest of the digits (34, 12),
End: if overflowed set the final overflow status.

On 8/19/08, Roger Bowler <rogerbowler@...> wrote:
>
> Just to complicate matters further, Intel pointers are
> "back-to-front", so for example 12345678 is stored in Intel storage as
> 78563412 (I gave up wondering why about 10 years ago :-))

--
Mike A Schwab, Springfield IL USA http://geocities.com/maschwab/ for
software links

[Greg Smith-14]

On Tue, 2008-08-19 at 17:16 +0000, michealbutz2002 wrote:

> I am a an Assembler internals Guy and am trying to expand my
> horizons  
>
> I am trying to display MVS info e.g. some of the things in HSCCMD.C
>
> In a GUI front I did a Windows API CreateProcess to Create a Window
> 32 WinMain app to display info displayed in DOS box from hsccmd.c
>
>
> you have given me some idea of what I need to do
>
> let me see if this can help

What Roger said.  Stuff in mainstor is big-endian.  Stuff in control
blocks is usually host-endian (little-endian on intel).  You should
always know how many bytes you are fetching from mainstor (whereas on
host you don't know if `void *ptr' is 4, 8 or some other number of
bytes).

To do virtual addressing, you should use the MADDR macro.  The control
regs (2 (primary) or 7 (secondary) or 13 (home) or etc) must be set up.
The virtual address should probably be resolvable to a real address else
you are going to take a page interrupt.

Below is some code I wrote a while back that fits into an instruction.

Bonus points to anyone that can explain what it does ;-)

Extra bonus points if you can explain why this code shows you cannot
necessarily trust your hardware vendor.

Greg

--- hercules-cvs/general2.c 2007-01-13 02:21:48.000000000 -0500
+++ hercules/general2.c 2007-02-04 13:03:06.000000000 -0500
@@ -1373,6 +1373,24 @@
     }
 #endif
 
+    if (i == 131 && sysblk.stepaddr[0] == 131)
+    {
+        BYTE *mn = NULL;
+        ARCH_DEP(display_inst)(regs, inst);
+        if (regs->GR_L(1))
+            mn = MADDR(regs->GR_L(1),0,regs,ACCTYPE_READ,0);
+        else if (regs->GR_L(0))
+        {
+            VADR p;
+            p = fetch_fw(MADDR(regs->GR_L(0)+4,0,regs,ACCTYPE_READ,0)); // SAFP
+            if (p && fetch_hw(MADDR(p+0x0c,0,regs,ACCTYPE_READ,0)) == 0x0005)
+               mn = MADDR(p + fetch_hw(MADDR(p+0x08,0,regs,ACCTYPE_READ,0)),
+                          0,regs,ACCTYPE_READ,0);
+        }
+        if (mn && (mn[3] & 0x80) == 0x00)
+            mn[3] |= 0x08;
+    }
+
     /* Point to PSA in main storage */
     psa = (void*)(regs->mainstor + px);
 

[michealbutz2002]

I thought control register 4 is the primary address space and 3 is
secondary


BTW

 if i am correct the control register 4 is the primary address

would the following code make sense

 if(regs->CR_HHL(4) == myasid)

Greg I have another question re: code you wrote I'll start another
thread  


--- In hercules-390@..., Greg Smith <gsmith@...> wrote:

>
> On Tue, 2008-08-19 at 17:16 +0000, michealbutz2002 wrote:
> > I am a an Assembler internals Guy and am trying to expand my
> > horizons  
> >
> > I am trying to display MVS info e.g. some of the things in HSCCMD.C
> >
> > In a GUI front I did a Windows API CreateProcess to Create a Window
> > 32 WinMain app to display info displayed in DOS box from hsccmd.c
> >
> >
> > you have given me some idea of what I need to do
> >
> > let me see if this can help
>
> What Roger said.  Stuff in mainstor is big-endian.  Stuff in control
> blocks is usually host-endian (little-endian on intel).  You should
> always know how many bytes you are fetching from mainstor (whereas on
> host you don't know if `void *ptr' is 4, 8 or some other number of
> bytes).
>
> To do virtual addressing, you should use the MADDR macro.  The control
> regs (2 (primary) or 7 (secondary) or 13 (home) or etc) must be set up.
> The virtual address should probably be resolvable to a real address else
> you are going to take a page interrupt.
>
> Below is some code I wrote a while back that fits into an instruction.
>
> Bonus points to anyone that can explain what it does ;-)
>
> Extra bonus points if you can explain why this code shows you cannot
> necessarily trust your hardware vendor.
>
> Greg
>
> --- hercules-cvs/general2.c 2007-01-13 02:21:48.000000000 -0500
> +++ hercules/general2.c 2007-02-04 13:03:06.000000000 -0500
> @@ -1373,6 +1373,24 @@
>      }
>  #endif
>  
> +    if (i == 131 && sysblk.stepaddr[0] == 131)
> +    {
> +        BYTE *mn = NULL;
> +        ARCH_DEP(display_inst)(regs, inst);
> +        if (regs->GR_L(1))
> +            mn = MADDR(regs->GR_L(1),0,regs,ACCTYPE_READ,0);
> +        else if (regs->GR_L(0))
> +        {
> +            VADR p;
> +            p =

fetch_fw(MADDR(regs->GR_L(0)+4,0,regs,ACCTYPE_READ,0)); // SAFP
> +            if (p && fetch_hw(MADDR(p+0x0c,0,regs,ACCTYPE_READ,0))
== 0x0005)
> +               mn = MADDR(p +
fetch_hw(MADDR(p+0x08,0,regs,ACCTYPE_READ,0)),
> +                          0,regs,ACCTYPE_READ,0);
> +        }
> +        if (mn && (mn[3] & 0x80) == 0x00)
> +            mn[3] |= 0x08;
> +    }
> +
>      /* Point to PSA in main storage */
>      psa = (void*)(regs->mainstor + px);
>

[fish-8]

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greg Smith wrote:
[...]
> Below is some code I wrote a while back that fits into
> an instruction.
>
> Bonus points to anyone that can explain what it does ;-)
>
> Extra bonus points if you can explain why this code shows
> you cannot necessarily trust your hardware vendor.

Well I can't answer using specifics but in general terms I'm guessing
it bypasses some sort of RACF security mechanism:

  http://tinyurl.com/5welex

Exactly *what* it's doing I don't know (since I'm not a z/OS person
and thus don't know much of anything about RACF other than that it
has something to do with z/OS security), but I'm guessing that by
turning on the X'08' bit in some RACF control block it's allowing you
to access something you otherwise wouldn't normally be allowed to
access.

It looks like it's triggered via setting an instruction-stepping
value of 131, e.g. "s 131".

Am I close? :)

- --
"Fish" (David B. Trout) - fish(at)infidels.org
Fight Spam! Join CAUCE! <http://www.cauce.org/>
7 reasons why HTML email is a bad thing
http://www.georgedillon.com/web/html_email_is_evil.shtml
PGP key fingerprints:
RSA: 6B37 7110 7201 9917 9B0D 99E3 55DB 5D58 FADE 4A52
DH/DSS: 9F9B BAB0 BA7F C458 1A89 FE26 48F5 D7F4 C4EE 3E2A

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1

iQA/AwUBSKvwmEj11/TE7j4qEQIZcgCdEglyaN0EhxTLd8w9HgOCNwvLgLkAoOR5
sSrqBIsyaPPYcIWE8rqxu4sS
=9jLV
-----END PGP SIGNATURE-----

[fish-8]

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

michealbutz2002 wrote:

> I thought control register 4 is the primary address space
> and 3 is secondary

CR4 = PASN (Primary Address-Space NUMBER) and CR3 = SASN (Secondary
Address-Space NUMBER).

CR1 = Primary Address-Space-CONTROL element (PASCE = a pointer to the
primary address space's Primary Region- or Segment-table, etc, used
in Dynamic Address Translation (DAT)). CR7 and CR13 are the same
thing but for translating Secondary and Home address space virtual
addresses.

- --
"Fish" (David B. Trout) - fish(at)infidels.org
Fight Spam! Join CAUCE! <http://www.cauce.org/>
7 reasons why HTML email is a bad thing
http://www.georgedillon.com/web/html_email_is_evil.shtml
PGP key fingerprints:
RSA: 6B37 7110 7201 9917 9B0D 99E3 55DB 5D58 FADE 4A52
DH/DSS: 9F9B BAB0 BA7F C458 1A89 FE26 48F5 D7F4 C4EE 3E2A

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1

iQA/AwUBSKv060j11/TE7j4qEQJvLwCgm+TakuDSC8Rcy1FouhPbxubx08sAoN88
lt15Z7O4Y6MNbCTC4xz6jQqn
=R41V
-----END PGP SIGNATURE-----