- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: GETJPIW hanging in UWSS
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
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
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
тАО07-09-2009 05:33 AM
тАО07-09-2009 05:33 AM
Re: GETJPIW hanging in UWSS
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-09-2009 06:11 AM
тАО07-09-2009 06:11 AM
Re: GETJPIW hanging in UWSS
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-10-2009 11:50 AM
тАО07-10-2009 11:50 AM
Re: GETJPIW hanging in UWSS
[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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-10-2009 01:25 PM
тАО07-10-2009 01:25 PM
Re: GETJPIW hanging in UWSS
http://labs.hoffmanlabs.com/node/1349
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-10-2009 02:23 PM
тАО07-10-2009 02:23 PM
Re: GETJPIW hanging in UWSS
http://digiater.nl/openvms/freeware/v80/gtm/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-10-2009 09:48 PM
тАО07-10-2009 09:48 PM
Re: GETJPIW hanging in UWSS
> [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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-10-2009 10:22 PM
тАО07-10-2009 10:22 PM
Re: GETJPIW hanging in UWSS
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-11-2009 07:37 AM
тАО07-11-2009 07:37 AM
Re: GETJPIW hanging in UWSS
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-13-2009 02:58 PM
тАО07-13-2009 02:58 PM
Re: GETJPIW hanging in UWSS
> 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
- « Previous
-
- 1
- 2
- Next »