Hi Oak,

The seL4 kernel does not have such primitives. You would need to build something with those semantics at user level. Typically you would do this by revoking authority and then granting it again. I don't understand how your system is structured if your initial process (which I guess is turning into your manager process) is calling remap. Does the initial process share part of its cspace with process A to be able to directly invoke its capabilities?

What seL4 can do is authority revocation. For example you could give process A read/write capabilities to the frames in question, and then when you want to remove access you could revoke the parent capability (this deleting the delegating read/write capabilities) and then give it a read only capability. I forget the exact details on cap depth for delegations but you might be able to give process A both a read/write capability and read only capability and just revoke the read/write one (and then later give it back). The idea here that process A can use the read/write capability, when it exists, to create read/write mappings, otherwise it must use the read only capability, which can only create read only mappings.

That is just one potential off the cuff design idea. Probably there are better designs, especially given I do not know the actual architecture of the system you are trying to build, but maybe this gives you some ideas.

Adrian

On Thu 08-Jun-2017 2:40 PM, Norrathep Rattanavipanon wrote:

Hello,

I have a question regarding the best way to temporally disable write-access on memory pages. Suppose in the user-space, there are two processes: initial user-space process and process A, which is created by the initial process. Process A has its own virtual memory space.

Now we want to find a way to enforce the memory inside process A to be temporally R/O to process A (since we want to have the initial process compute a function on that memory snapshot.) Currently, what we are doing now is to lock all memory pages of process A by calling the "remap" function inside the initial process.

But then we realize that doing that does not help much. Since process A owns capabilities to its memory pages, process A also can call "remap" function to unlock the locked memory pages (please correct me if it's wrong). This will cause the memory to be inconsistent when computing a function on that memory.

My question is is there anyway to enforce how a page locking (make it R/O) works in seL4 so that ONLY the entity that locked the page can unlock it? For example, in this case, we want to make sure that only the initial process can unlock the pages that he locked earlier.

Thank you,

Oak

--

Norrathep (Oak) Rattanavipanon
M.S. in Computer Science

University of California - Irvine
_______________________________________________
Devel mailing list
Devel@sel4.systems
https://sel4.systems/lists/listinfo/devel