[Info-vax] Calling LIBOTS routines above ASTDEL

[Stephen Hoffman]

On 2019-04-19 16:03:13 +0000, osuvman50 at gmail.com said:

> I was looking at some inner mode code and saw the author had called 
> OTS$MOVE to copy a buffer after raising IPL to driver fork. The code 
> wasn't explicitly calling it but was doing so by way of the C compiler 
> treating memcpy() as intrinsic. LIBOTS is usually installed resident, 
> does that mean it's in non-pageable memory?

Best to link with and use the kernel C RTL here and the kernel APIs, 
and possibly to use an available device driver call such as 
ioc_std$movfruser call, depending on exactly what's happening here and 
why.

Images installed resident are not paged.  Not sure I'd assume that's 
the only associated memory for an arbitrary RTL call as some RTL calls 
might use the heap, but the ots$move code itself is probably okay.

AFAIK, none of the RTL calls are considered supported for calls from 
inner-mode code.  Not that the documentation seems to make that 
restriction abundantly clear.

The C driver book references this kernel-mode programming topic 
somewhat indirectly, buried in the LINK command.  Use of /NOSYSSHR is 
required.  Use of that qualifier means that RTL-based calls won't 
resolve.  Quoth the tome, "Drivers may not resolve symbols from 
shareable image libraries".  If I were ever rewording that section, I'd 
probably replace that with "Drivers shall not resolve symbols from 
shareable image libraries", too.

Do check with the folks at VSI or HPE for the official word on this.

Errant inner-mode calls to RTL calls that use the heap may well open 
security vulnerabilities and paths to exploits, too.

TL;DR: no way I'd try that.


-- 
Pure Personal Opinion | HoffmanLabs LLC