From: ROW::EVERHART 23-DEC-1996 12:06:12.25 To: 3049::"rick@rdperf.com" CC: EVERHART Subj: RE: DKDRIVER & Device I/O Intercept Rick - Good to have your address. If you recall (or even if you don't ;-) ) I met you some years ago when you gave a talk at a DECUS symposium on I/O interception, and mentioned you'd donate a template intercept driver to the sigtapes. (Never did get hold of you afterwards, but I wrote my own and put it out instead.) The problem currently is with only DKdriver on alpha, though other Alpha drivers may need something similar. The listings got censored in 6.2 (I got em uncensored for 7.1 finally!) which is when the problem started. Basically the deal is that dkdriver was blowing knl stack when trying to call the driver start-io every time, so it got altered to just loop around internally in start_io to look for more work. There's no ready external place to hook this, and insioq(c) just call the insert IRP entry directly, again with noplace to steal things. exe_std$insert_irp (spellinf from memory) only needs a queue header address and an element address, making it hard to use the fact that R5 usually points to the victim UCB at the call for anything useful. I'm working up some plans for a fixup, and have actual test code running that alters sysqioreq so that the insert-irp entry gets called for drivers via the driver pending-io entry (which can be trapped). You have to be able to rebuild IO_ROUTINES.EXE to use this, but the mod is tiny. Unfortunately all this got done before I got here, or I'd have warned folks about it. DKdriver sets its UCB busy a fair amount during error conditions, when internal SCSI device queues signal busy, during io datacheck ops, at mount verify or cluster state transition, and some more, so you can't count on it not being set. In all of the sys facility, only sysqioreq, mbdriver, and nldriver refer to EXE_STD$INSERT_IRP and that's just due to the DDTAB macro for the drivers, so it is conceivable to just steal the entry of insert-irp and pray that nothing else calls it, and look at the UCB and thus get a look at IRPs on their way in. For the moment that's the only game in town. My hack may make it into sysqioreq for the next rev, and maybe into a 1H release, but it'll miss 7.1...that is too close to release and I didn't find out about the full magnitude of the screwup (well, I consider it one) till too late to wedge a mod to sysqioreq into 7.1. Too much testing's called for. What I'd really LIKE to see is a series of mods to the i/o exec that will have a stack space in each IRP for intermediate status etc. type stuff, and another ddtab entry for the looping issues that may have to be handled from macro-64 but which would be used as a place which every IRP would have to pass by FROM INSIDE STARTIO, and which would not shove more junk on a stack, just call an address more or less bare and thus continue, no stack mods at all. It would need to be basically a jump target, but that needs to be somehow compilable on Alpha (in C for political etc. reasons) and would need to be useful somehow. That may turn out to be a tall order. If you have comments or even code suggestions, as a 3rd party ISV (who's still third party...my word on this is likely to be disvalued internally since my outside stuff...even what isn't on the market yet...gets viewed as not "really" outside) they may be quite helpful in getting some such mods made. I'd like to arrange that any Alpha drivers that play these games again have some method for just looking in ONE place for packets again. Having to look in several is a nuisance, to put it in the politest terms available. (Tis pity btw that your colleagues at Symark never got very far with my security stuff. Happened to be talking to a mainframer at a large insurance co. last week (who is dis-satisfied with IBM's next gen performance and seemed interested in that of VMS with VLM) and when I described my Safety package to him, he noted that --all unknown to me--apparently the major IBM mainframe security addons (stuff with names like RACF and Top Secret) do the same general operations. While I was disappointed to hear that someone had done some of the security stuff I had come up with out of my head, it was interesting to think that there's apparently at least one very large market with considerable money floating around needing exactly what I have. Symark and I corresponded a while but nothing ever came of it...while meanwhile I keep improving the pkg and adding stuff.) Back to topic. I'm working up a design spec for my multipath switching code (which can manage if at least the pending IO entry is stealable), I will be pushing for the IRP stack, the extra DDTAB entry, and a couple other interecept speedups I have running here in a section of that document. Provided that passes muster, a retrofit of at least sysqioreq should be simple enough. I may be able to even get that slipped out on the side as a copy of io_routines.exe for those who need it. Does this address your issues? Glenn C. Everhart Everhart@star.enet.dec.com (work) Everhart@Arisia.GCE.Com (home) 603 881 1497 office 603 465 9517 h 603 465 9518 fax (also everhart@gce.com works, or everhart@gce.mv.com)