GETJPIW hanging in UWSS

[Hoff]

Get out of kernel mode. Either entirely out of inner-mode code, or use an exec-mode exit handler if you can. I prefer to avoid maximizing the mode for these cases; I want to design to minimize use of inner-mode code. Or removing the inner-mode code in its entirety.

Executive and particularly kernel have limits in what you can call and what you can do. And a related factor: the LINK command that was used. Many user-mode calls don't work in kernel, so it's usually best to exclude those via the LINK.

Get out of the exit handler as quick as you can, too, and simplify the exit handler as much as you can. I've already posted my suggestions for alternatives.

If you want us to look at the code, then you're going to need to post (more of) it. From what code has been posted, I can't tell if that sys$getjpiw call is correctly constructed or if it is a latent system-crasher.

I just got done doing an exec-mode UWSS for a customer. They're (usually) not particularly difficult, but the rules and the limitations and the requirements are definitely not well documented.

[Hoff]

FWIW, a SYS ECO just popped out for OpenVMS I64 V8.3-1H1 with various fixes for problems in sys$getjpi. Some of these same issues may (or may not?) affect OpenVMS Alpha V8.2, and (if so) HP may or may not generate an ECO kit.

[Sam Weiner]

Richard,

[smw] The option file has "protect=yes". We are very careful to not do I/O in these routines and probe any addresses before use.

Well to answer my question in the interests of imparting useful information I guess the answer would be "Yes Richard, you are correct that we are not linking with /PROTECT"?

[smw2] I now understand the question better. There is only one protect= in the option file and it covers all modules in the image so I guess we could have used /protect instead.

2) Run an analyze/image of your UWSS and see what it's linking against

[smw2] The only image it is linking against is:

Shareable Image List

0) "SYS$PUBLIC_VECTORS"

Hoff,

Doing things in exec mode sounds interesting but as I understand it the rundown handler at least starts in kernel mode. However, I don't see us moving that way at this time. Maybe another time. I am going to create an item in our tracking system to look at this area more. When it will bubble up the priority list is another matter.

I'm attaching (if I did it right) the routine which does the getjpiw, the link /opt file, and the PLV. I probably should have done so earlier. The whole system is on sourceforge and even one of the VMS Freeware volumes if anyone really cares.

Again, thanks to all who responded.

Sam

[Hoff]

There's a kernel-mode rundown pointer in the PLV, and there's an exec-mode rundown pointer.

http://labs.hoffmanlabs.com/node/1349

[Hoff]

And here is a pointer to what looks to be the package in question:

http://digiater.nl/openvms/freeware/v80/gtm/

[Richard J Maher]

Hi Sam,

> [smw2] I now understand the question better.
> There is only one protect= in the option file
> and it covers all modules in the image so I
> guess we could have used /protect instead.

/PROTECT and protect=yes are not synonyms and not functionally identical.

> Shareable Image List
>
> 0) "SYS$PUBLIC_VECTORS"

Ok, let's stick with the same symptom but a different cause. I'm guessing (because you haven't left much choice) that there's lots of lock manager activity going on and that such locks are not likely to be held at Kernel mode? Either way, could you be experiencing a race condition where some/most times the locks have been cleaned-up (or never instantiated) before your Kernel rundown handler gets called, yet in some corner-cases you find yourself waiting in kernel mode for an exec mode AST to be delivered to your process?

Anyway, let me go crazily way out on a limb here and actually provide a small code example. The attached code can also be found at Mar 27, 2006 in: -
http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=940030

and

Feb 12, 2009 in: -
http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1312923

but as they could be out of date so I'll attach the coe again.

The example has relevance in that it is an Exec mode UWSS that does a CMKRNL when and only when it needs to. May not solve your problem, but if you stay in Exec mode most of the time then you'll certainly be rebooting your machine less :-)

So I suppose my last question (before I get to accuse the Rev. Hoff, in the Library, with the Pseudo-Device Driver :-) is "Is there anything *any circumstances* to cause your Kernel rundown handler to wait for something that will only be set from an outer mode?

Regards Richard Maher

[Richard J Maher]

Sam,

I've attached some documentation for the previous UWSS code here. Also, search my UWSS code for the word "churlish" and an example of waiting at a lower mode. (Maybe there is a bug in VMS that's affecting you, but I doubt it. I'd also like to see a good example of the WAIT_AT_CALLERS_MODE flag, but I doubt I'll see that also)

Hoff,

> I just got done doing an exec-mode UWSS for a customer.
> They're (usually) not particularly difficult,
> but the rules and the limitations and the requirements
> are definitely not well documented.

I just about fell off my chair at this volte-face to end all back-flips! But why no Pseudo-Device Driver? Hmmm?

Anyway, I hope Damascus was nice, and it's good to have you back in the fold! Care to share your example with us? What did it do? I'm sure Gilly is champing at the bit to critique your argument-stack probing and validation!

Cheers Richard Maher

[Hoff]

The UWSS-level probe operations (__PAL_PROBER, __PAL_PROBEW, et al) I used with the UWSS here were targeted toward maintaining the stability and integrity of the operating system; to avoid having an errant argument causing the exec-mode code to romp on something critical.

Mounting a security attack against this particular UWSS seems, well, more effort than just calling an obviously-named entry point to gain privileged access. The central purpose of this particular UWSS was to breach OpenVMS security, after all.

But it was fun to apply the memories of these areas of OpenVMS; of how to crack and how to harden a UWSS or a pseudo-device driver.

[Richard J Maher]

Hi Steve,

> Mounting a security attack against [this]
> particular UWSS seems, well, more effort
> than just calling an obviously-named entry
> point to gain privileged access. The
> central purpose of [this] particular UWSS
> was to breach OpenVMS security, after all.


Please define "this". Which/what UWSS are you talking about?

Cheers Richard Maher