Changing the page protection of reserved memory global sections with shared PTEs.

[Roger Tucker]

As usual – read this carefully – stay on the subject, and assume I know what I’m doing and why… OK. Now that I got that over with!

This is more of a question for Karen Noel or someone else on the VMS engineering team, although someone else out there may have some ideas as well...

We currently use a very large RESERVE MEMORY global section with shared PTEs. Our application both writes into this global section and reads from it with appropriate locking and concurrency control (our locking and memory management of this very large cache is very specialized, custom, and in kernel mode). The problem is, I wanted to protect areas of this memory from user-mode write access, but allow user-mode read. There are several reasons that someone might want to do this - guard pages for example, but in our case we want to improve our write control and protect ourselves from something going wrong. In this case, we would allow super-mode write access and jump to super when we need to write into the global section. But you can’t do this with the normal VMS system services – i.e. change the page protection of shared PTEs, or control read/write mode of global sections when created for each mode independently. But I just wanted to ask, if there was something I was missing before I write more kernel mode code to do what I need to do. For those of you with source code, start at $create_gdzro_int() in file SYS_GDZRO_64.LIS… I think the easiest way to do this, is to write my own version of sys$setprt_64() that doesn't have theses restrictions. In the future, it would be nice if theses restrictions on modifications of page protection of global sections with shared PTEs were not there, but I can also see why this was done. Any ideas or thoughts?

Very minor, but the documentation on sys$setprt_64() seems to be wrong when it comes to the page_protection bits.
The documentation says that bits 4 to 31 are ignored, but the 64 bit code shows it returning SS$_IVPROTECT if any bits other than 0-3 are set.

[faris_3]

Hi,

Are you trying to modify each process' access to the pages or directly the protection of the shared PTE ?

This is limited for security reasons :

"For pages in global sections, the new protection can alter only copy-on-reference pages."

$setprt only works on process page tables. OpenVMS has no mechanism to modify the protection of already existing global pages.

The problem is : what are you going to do with processes that have already mapped the page and would now no longer allowed to do so?

[Roger Tucker]

To answer the above questions:

>Are you trying to modify each process' >access to the pages or directly the >protection of the shared PTE?

Since all the processes share the same PTE's, you can only modify protection on the shared PTEs, and therefore all processes.

>This is limited for security reasons :
>"For pages in global sections, the new >protection can alter only copy-on->reference pages."

Yes, I can see why this was done, but I was still asking.

>$setprt only works on process page tables. >OpenVMS has no mechanism to modify the >protection of already existing global >pages.

Yes, I know... But when I'm done it will... :-)

>The problem is : what are you going to do >with processes that have already mapped >the page and would now no longer allowed >to do so?

Most of the processes read the global sections, that's why we want user-mode read access. Write access is very controlled and only done in a few places where we would just to supervisor mode before we perform the write. Like I said, we want a shared user-mode read, but supervisor mode write, shared PTEs for all processes reserved memory global section.

[Ian Miller.]

How do you create this global section?

[Roger Tucker]

This global section is created in the following way:

1. While in kernel mode, we scan the reserved memory sections list MMG$GL_RES_MEM_FLINK, to veryify the section name was reserved at boot time, that it has the right attributes, and we get the size of the reserved global section.

2. We create a 64 bit virtual region in P2 space using sys$create_region_64() and VA$M_SHARED_PTS using the size of step 1.

3. Then we create the actual global section using sys$crmpsc_gdzro_64() in the region created by step 2. mode=USER...

Result, all pages are user-mode read and write using shared PTEs in a P2 64 bit virtual address space. I love VMS.

[Ian Miller.]

Roger,
I suspect that my GBLSEC SDA extension will not work with your global section as it is in a user created region. Before I look at fixing this can you check its behaviour (on a test system obviously).

GBLSEC can be download from ftp://ftp.process.com/vms-freeware/fileserv/gblsec_sda.zip

or my web site
http://www.encompasserve.org/~miller/

I suspect GBLSEC will display information correctly but will not find processes mapped to the global section.

[Richard J Maher]

Hi Rodger,

Have you managed to make any progress with this? I'm afraid that I will also be of limited use to you as I too have more questions than answers. But let me at least add my voice to yours in calling for what seems to be a very basic, yet very useful, requirement.

First off, can someone please explain exactly why the historical restriction of only ever being able to specify one access mode for both read and write access to a global section has been enforced? Everyone else seems to say something like "I know why it does it" well I, for one, don't. Outer-mode read, inner-mode write seems as natural as VMS itself, so why has this option never been available?

I thought that Roger may have been able to simply map the section twice, once with sec$m_wrt and once without, but sadly this option is also not available.

So unless Roger has come up with something since Christmas, I guess we're all stuck with going into inner-mode for both read and write. I've attached an example that I knocked-up a couple of years ago when VLM was new(ish). Although this is not Kernel mode code, it used to crash the system if certain XFC options were turned on :-( I believe those to have been fixed post 7.3-2 but you will note that the EXEC mode rundown *must* fire all the time or something to do with buffer objects used to crash the system. As I said, my code is all Exec mode. Blame VMS.

Before I go Roger, a couple of questions if I may: -

1) What's wrong with inner-mode for both read and write? Expensive in terms of performance? Does your system do air-traffic control or something? If you've gone to the trouble of doing your own lightweight locking then clearly performance is critical, but a bit of background would be nice for interest's sake if nothing else :-)

2) Why Supervisor mode and how do you get there? Cheaper than Exec?

3) Is everone saying that Roger's requirement is doable if he only had process private page tables? Map it as SRSW then $setprt all of them to URSW?

Cheers Richard

PS. "Iii liiiike, BIG_BUFFs that I can't de-nie!" :-)

[Richard J Maher]

Hi Again,

Here's the initialization stuff that is needed before you can run BIG_BUFFS.

It's a crying shame that Rdb engineering never embraced this VLM functionality in the same way that Orrible Oracle did :-( Still Norm Lastovica was saying only last year that they're planning on doing something, so who knows?

Cheers Richard Maher

[Roger tucker_1]

Richard,

thanks for all of your thoughts on this. We can't use private PTE's because of the size of this global section and the number of processes that need to map it (it would waist too much memory). I can't go into detail on this application, but it's a large, very high speed, custom, real-time database, with custom memory management and locking -- we do 4.5 Billion database lookups per day and millions of updates. We have been using this technique for many years with improvements along the way (even wrote it ourselves in kernel mode) long before VLM existed. OpenVMS rocks...