- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: System Service Interception on OpenVMS
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-29-2012 02:02 AM
05-29-2012 02:02 AM
Re: System Service Interception on OpenVMS
I know, it doesn't help, but it works for me (on OpenVMS V8.3, node EISNER, AlphaServer DS20 500 MHz). I took the Example 3-1 "Use of the Create, Open, and Close Services" from http://h71000.www7.hp.com/doc/731final/4523/4523pro_002.html, changed my example to count sys$connect and created a shareable image with image initialization out of it; I linked the RMS example against it an ran it: the shown count is two.
Sorry, I don't have the time (but you can hire me any time :-) to do more testing and I don't have the same environment as you have: I have no idea why it doesn't work for you and V7.3-2.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-29-2012 03:55 PM
05-29-2012 03:55 PM
Re: System Service Interception on OpenVMS
FWIW,
I worked out an ugly way to translate system service PDs into names. I use a macro to build a table of value pairs (PD,descriptor address), like this:
.PSECT Table,RD,WRT,NOEXE,QUAD MaxTbl: .LONG 0 K_MaxTbl=0 SymTbl: .MACRO RTN nam .PSECT Const .ALIGN QUAD S%EXTRACT(0,30,nam): .ASCID /'nam'/ .PSECT Table .ADDRESS 'nam' .ADDRESS S%EXTRACT(0,30,nam) K_MaxTbl=K_MaxTbl+1 .ENDM RTN RTN SYS$QIOW RTN SYS$CLI RTN SYS$ADJSTK RTN SYS$ADJWSL RTN SYS$ALCDNP ...
The list of routine names is taken from SYS$SSISHR entry points. At run time, the table is sorted on PD value at initialisation. To determine a system service name do a binary search for the PD value, which gives the address of the string descriptor.
Regarding JohnRD's question about RMS services. I see a curious behaviour. If I link against SYS$SSISHR without DEBUG and just RUN the image I catch those system services which the image calls directly. Here's the beginning and end of a run of Hein's "STRINGS" program running against itself:
SSI 30-MAY-2012 08:38:35.54 SYS$OPEN From: 00030A98 AP: 1 00000000 SSI 30-MAY-2012 08:38:35.54 SYS$CONNECT From: 00030AC4 AP: 1 00000000 SSI 30-MAY-2012 08:38:35.54 SYS$GET From: 00030B64 AP: 1 00000000 STRINGS SSI 30-MAY-2012 08:38:35.54 SYS$GET From: 00030B64 AP: 1 00000000 SYS$SSISHR_001 LIBRTL_001 LIBOTS_001 SSI 30-MAY-2012 08:38:35.54 SYS$GET From: 00030B64 AP: 1 00000000 SSI 30-MAY-2012 08:38:35.54 SYS$GET From: 00030B64 AP: 1 00000000 ... DSC$K_CLASS_S DSC$K_DTYPE_T START SSI 30-MAY-2012 08:38:35.60 SYS$GET From: 00030B64 AP: 1 00000000 SSI_FINDENTRY SSI_FIXTABLE SSI_STOP SSI_FORMATARGS SSI_START SSI_POST SSI_PRE SSI 30-MAY-2012 08:38:35.60 SYS$GET From: 00030B64 AP: 1 00000000 SSI 30-MAY-2012 08:38:35.60 SYS$CLOSE From: 00030AF4 AP: 1 00000000 SSI Pre: In 000004E3 Act 000001A1 Post: Out 000004E3 act 000001A1
Notice that the output lines (written with LIB$PUT_OUTPUT) don't trigger any traces for the services they obviously call. Also note the counters on the final line. Exactly the same program, run under DEBUG
OpenVMS Alpha Debug64 Version V8.3-016 %DEBUG-I-INITIAL, Language: AMACRO, Module: .MAIN. DBG> go SSI 30-MAY-2012 08:35:50.57 SYS$CLI From: 810BE254 AP: 1 00000000 SSI 30-MAY-2012 08:35:50.57 SYS$OPEN From: 00030A48 AP: 1 00000000 SSI 30-MAY-2012 08:35:50.57 SYS$CONNECT From: 00030A68 AP: 1 00000000 SSI 30-MAY-2012 08:35:50.57 SYS$GET From: 00030AEC AP: 1 00000000 SSI 30-MAY-2012 08:35:50.57 SYS$PUT From: 810C20C4 AP: 1 00000000 STRINGS SSI 30-MAY-2012 08:35:50.57 SYS$GET From: 00030AEC AP: 1 00000000 SSI 30-MAY-2012 08:35:50.57 SYS$PUT From: 810C20C4 AP: 1 00000000 SYS$SSISHR_001 SSI 30-MAY-2012 08:35:50.57 SYS$PUT From: 810C20C4 AP: 1 00000000 LIBRTL_001 SSI 30-MAY-2012 08:35:50.57 SYS$PUT From: 810C20C4 AP: 1 00000000 LIBOTS_001 SSI 30-MAY-2012 08:35:50.57 SYS$GET From: 00030AEC AP: 1 00000000 SSI 30-MAY-2012 08:35:50.57 SYS$GET From: 00030AEC AP: 1 00000000 ... SSI 30-MAY-2012 08:35:52.18 SYS$PUT From: 810C20C4 AP: 1 00000000 DSC$K_CLASS_S SSI 30-MAY-2012 08:35:52.18 SYS$PUT From: 810C20C4 AP: 1 00000000 DSC$K_DTYPE_T SSI 30-MAY-2012 08:35:52.18 SYS$PUT From: 810C20C4 AP: 1 00000000 START SSI 30-MAY-2012 08:35:52.18 SYS$GET From: 00030AEC AP: 1 00000000 SSI 30-MAY-2012 08:35:52.18 SYS$PUT From: 810C20C4 AP: 1 00000000 SSI_FINDENTRY SSI 30-MAY-2012 08:35:52.18 SYS$PUT From: 810C20C4 AP: 1 00000000 SSI_FIXTABLE SSI 30-MAY-2012 08:35:52.18 SYS$PUT From: 810C20C4 AP: 1 00000000 SSI_STOP SSI 30-MAY-2012 08:35:52.18 SYS$PUT From: 810C20C4 AP: 1 00000000 SSI_FORMATARGS SSI 30-MAY-2012 08:35:52.18 SYS$PUT From: 810C20C4 AP: 1 00000000 SSI_START SSI 30-MAY-2012 08:35:52.18 SYS$PUT From: 810C20C4 AP: 1 00000000 SSI_POST SSI 30-MAY-2012 08:35:52.18 SYS$PUT From: 810C20C4 AP: 1 00000000 SSI_PRE SSI 30-MAY-2012 08:35:52.18 SYS$GET From: 00030AEC AP: 1 00000000 SSI 30-MAY-2012 08:35:52.18 SYS$CLOSE From: 00030A8C AP: 1 00000000 SSI Pre: In 000063CD Act 000018F2 Post: Out 000063CD act 000018F2 %DEBUG-I-EXITSTATUS, is '%SYSTEM-S-NORMAL, normal successful completion'
Now we see the SYS$PUTs from LIB$PUT_OUTPUT and the counters are much higher. I guess it depends on when the fixups are done how the SSI effects calls from lower level shareable images. It explains my earlier observation that I got no output, as my test program in that case had no direct system service calls. Could be seen as a feature.
My next puzzle is why the arguments of the RMS services are all 0! Also, DEBUG issues a constant stream of $SETIMR/$WAITFR pairs. I need to work out a simple way to recognise and bypass system service calls originating from DEBUG. The from address should help, but it's non-trivial!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-29-2012 06:21 PM
05-29-2012 06:21 PM
Re: System Service Interception on OpenVMS
Proof of concept.
I added a bypass in the PRE routine for "from" address within a particular range.
Running the under DEBUG and using SHOW IMAGE to find the start and end addresses for the DEBUG image and manually DEPOSIT those values into the range check.
I can now set a break point to the active section of the PRE address without sending DEBUG into a recursion loop.
Next step is to find a reasonably clean way to automatically detect the DEBUG image and set the range...
Using this trick with DEBUG I was able to confirm that the argument list SSI gets for the RMS services is indeed count=1 fiist arg=0. Not sure why.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-30-2012 01:28 AM
05-30-2012 01:28 AM
Re: System Service Interception on OpenVMS
>>> I guess it depends on when the fixups are done how the SSI effects calls from lower level shareable images.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-30-2012 03:31 PM
05-30-2012 03:31 PM
Re: System Service Interception on OpenVMS
>> Or put it another way, if you have a "low level shareable image" linked against sys$public_vectors, you can't fix it up against sys$ssishr
Fair enough, but that doesn't explain the observation. How are we catching system service calls from low level shareable images? Here's the result matrix:
Image Image Liked
Run /NODEBUG /DEBUG
/NODEBUG Direct Only All Calls
/DEBUG All Calls All Calls
Note that in all cases the image itself is linked against SYS$SSISHR (has to be to resolve the calls to DECLARE_INTERCEPT).
My evidence for "All Calls" is I'm catching SS calls with FROM addresses in LIBRTL.
JG> JG> macro/noopt/deb strings+[-]util/lib JG> link strings+ssishr/opt First run, LINK/NODEBUG RUN/NODEBUG. Only one direct call was caught. JG> run strings SSI 31-MAY-2012 07:56:25.74 SYS$GETTIM From: 00030B14 AP: 1 00000000 Please enter filename: SSI Pre: In 00000003 Act 00000001 Post: Out 00000003 act 00000001 Second run LINK/NODEBUG RUN/DEBUG. Direct and indirect calls caught. The block of calls from SYS$CLI to SYS$GET are from LIB$GET_FOREIGN. Note that the LIBRTL addresses are in S0 space - so they're from the resident image. JG> run/debug strings %DEBUG-I-NOGLOBALS, some or all global symbols not accessible OpenVMS Alpha Debug64 Version V8.3-016 %DEBUG-I-INITIAL, Language: AMACRO, Module: STRINGS DBG> go SSI 31-MAY-2012 07:56:54.89 SYS$GETTIM From: 00030B14 AP: 1 00000000 SSI 31-MAY-2012 07:56:54.89 SYS$CLI From: 810BE254 AP: 1 00000000 SSI 31-MAY-2012 07:56:54.89 SYS$SETAST From: 810BEA14 AP: 1 00000000 SSI 31-MAY-2012 07:56:54.89 SYS$READ_THR From: 810BEA2C AP: 1 00000000 SSI 31-MAY-2012 07:56:54.89 SYS$OPEN From: 810BEB68 AP: 1 00000000 SSI 31-MAY-2012 07:56:54.89 SYS$CONNECT From: 810BEC94 AP: 1 00000000 SSI 31-MAY-2012 07:56:54.89 SYS$SETAST From: 810BEDD4 AP: 1 00000000 SSI 31-MAY-2012 07:56:54.89 SYS$GET From: 810BF1E4 AP: 1 00000000 Please enter filename: Exit SSI Pre: In 00000025 Act 00000008 Post: Out 00000025 act 00000008 %DEBUG-I-EXITSTATUS, is '%RMS-E-EOF, end of file detected' DBG> set image librtl DBG> examine 810BE254 %DEBUG-E-INVPD, procedure descriptor at 00000000000E3198 is not valid. LIB$GET_FOREIGN\LIB$GET_FOREIGN\%LINE 545: LDL R5,#X0020(FP) DBG> exit Third run LINK/DEBUG RUN/NODEBUG direct and indirect calls caught. JG> link/debug strings+ssishr/opt JG> run/nodeb strings SSI 31-MAY-2012 07:57:13.40 SYS$GETTIM From: 00030B14 AP: 1 00000000 SSI 31-MAY-2012 07:57:13.40 SYS$CLI From: 810BE254 AP: 1 00000000 SSI 31-MAY-2012 07:57:13.40 SYS$SETAST From: 810BEA14 AP: 1 00000000 SSI 31-MAY-2012 07:57:13.40 SYS$READ_THR From: 810BEA2C AP: 1 00000000 SSI 31-MAY-2012 07:57:13.40 SYS$OPEN From: 810BEB68 AP: 1 00000000 SSI 31-MAY-2012 07:57:13.40 SYS$CONNECT From: 810BEC94 AP: 1 00000000 SSI 31-MAY-2012 07:57:13.40 SYS$SETAST From: 810BEDD4 AP: 1 00000000 SSI 31-MAY-2012 07:57:13.40 SYS$GET From: 810BF1E4 AP: 1 00000000 Please enter filename: Exit SSI Pre: In 00000025 Act 00000008 Post: Out 00000025 act 00000008 %RMS-E-EOF, end of file detected Fourth run LINK/DEBUG RUN/DEBUG direct and indirect calls caught. JG> run/debug strings OpenVMS Alpha Debug64 Version V8.3-016 %DEBUG-I-INITIAL, Language: AMACRO, Module: STRINGS DBG> go SSI 31-MAY-2012 07:57:29.17 SYS$GETTIM From: 00030B14 AP: 1 00000000 SSI 31-MAY-2012 07:57:29.17 SYS$CLI From: 810BE254 AP: 1 00000000 SSI 31-MAY-2012 07:57:29.17 SYS$SETAST From: 810BEA14 AP: 1 00000000 SSI 31-MAY-2012 07:57:29.17 SYS$READ_THR From: 810BEA2C AP: 1 00000000 SSI 31-MAY-2012 07:57:29.17 SYS$OPEN From: 810BEB68 AP: 1 00000000 SSI 31-MAY-2012 07:57:29.17 SYS$CONNECT From: 810BEC94 AP: 1 00000000 SSI 31-MAY-2012 07:57:29.17 SYS$SETAST From: 810BEDD4 AP: 1 00000000 SSI 31-MAY-2012 07:57:29.17 SYS$GET From: 810BF1E4 AP: 1 00000000 Please enter filename: Exit SSI Pre: In 00000025 Act 00000008 Post: Out 00000025 act 00000008 %DEBUG-I-EXITSTATUS, is '%RMS-E-EOF, end of file detected' DBG> set image librtl DBG> examine 810BE254 %DEBUG-E-INVPD, procedure descriptor at 00000000000E3198 is not valid. LIB$GET_FOREIGN\LIB$GET_FOREIGN\%LINE 545: LDL R5,#X0020(FP)
Note that the LIBRTL calls are coming from S0 space, so they're the RESIDENT image (ShareAddr!). How are we catching those, and why does it depend on /DEBUG?
Here's what the call stack looks like inside SSI_PRE when called through LIBRTL
DBG> show calls
module name routine name line rel PC abs PC
SHARE$SIMPLE 000000000000098C 000000000003098C
SHARE$SYS$SSISHR 0000000000010C64 000000000018CC64
SHARE$SYS$SSISHR 0000000000011884 000000000018D884
*LIB$GET_INPUT DO_GET 1851 0000000000000548 FFFFFFFF810BEB68
----- the above looks like a null frame in the same scope as the frame below
*LIB$GET_INPUT ? ?
*LIB$GET_INPUT LIB$GET_INPUT
1569 000000000000020C FFFFFFFF810BE82C
----- the above looks like a null frame in the same scope as the frame below
*LIB$GET_INPUT ? ?
%DEBUG-E-INVPD, procedure descriptor at 00000000000E3198 is not valid.
*LIB$GET_FOREIGN
LIB$GET_FOREIGN
601 0000000000000294 FFFFFFFF810BE414
----- the above looks like a null frame in the same scope as the frame below
*LIB$GET_FOREIGN ? ?
SHARE$SIMPLE 0000000000000AF8 0000000000030AF8
FFFFFFFF8038BDD4 FFFFFFFF8038BDD4
(Another ugly hack to work out where DEBUG is... I'm using LIB$FIND_IMAGE_SYMBOL to locate both symbols exported from the DEBUG shareable image. I've determined their offsets from the beginning and end of the image and hard coded them as constants. At run time, I add (or subtract) the offsets from both symbols, sanity check that both symbols yield the same results and use the resulting range to exclude FROM addresses from processing in the PRE routine. This is obviously dependent on the version of DEBUG)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-31-2012 03:21 AM
05-31-2012 03:21 AM
Re: System Service Interception on OpenVMS
>>> Note that the LIBRTL calls are coming from S0 space, so they're the RESIDENT image (ShareAddr!). How are we catching those, and why does it depend on /DEBUG?
I no longer have access to the sources so I can't read the real documentation. I re-read Ruth's paper on ssi and she proves me wrong, fixups aren't always fixed :-(
However, that didn't match what I saw, so far, but wait ...
Usually LIBRTL is installed /resident and /share=addr. So it seems a reasonable assumption that "coming from S0" means, it also uses shared address data. But in general /resident is independent of shared address data. So the asumption is not always true. Shared address data means sharing the linkage sections and pre-applying fixups during INSTALLation of the image. As you show, you can intercept system services from LIBRTL: either you have a private and modified copy of the shared address data in P0 or /DEBUG does some magic. It seems to be the first.
$
It seems that the image activator can't change the shared data of the installed images and didn't bother to tell us about it. I miss the real documentation, here. Also, if you run /DEBUG you get private copies of all the P1 sections, including the shared data. You can verify that from SDA and you will also see that code is still in S0 space.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-13-2012 12:32 AM
06-13-2012 12:32 AM
Re: System Service Interception on OpenVMS
What are the chances of HP ever publishing the documentation on SSI?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-13-2012 07:33 PM
06-13-2012 07:33 PM
Re: System Service Interception on OpenVMS
>What are the chances of HP ever publishing the documentation on SSI?
If no one formally asks for it, ZERO. HP is a very metrics driven culture. The days of people being able to do things just because it's the right thing to do are long gone. Everything must have a measurable payoff.
Even if you formally ask, I think it's a long shot. The folk who actually know this stuff are also long gone :-(
That said, here's another (tiny) piece of the puzzle. It looks to me like the argument list passed to the PRE action routine is an array of QUADWORDS, not a VAX type argument list (longwords). That explains my puzzle of the 0 arguments to RMS services. Interpreting the argument list as quadwords gives more plausible values.
Please lodge a formal request for the documentation against your HP services contract.
- « Previous
-
- 1
- 2
- Next »