[seL4] Change Access Right to Memory Pages

Norrathep Rattanavipanon nrattana at uci.edu
Tue May 2 15:32:09 AEST 2017

Hi Adrain and Gernot,

Thank you for the clarification. Yes, sorry, forgot to mention that we are
using ARM i.MX6 Sabre Lite and forgot to mention some backgrounds.

We are interested in benchmarking (1) the time to lock large memory regions
(switching from R/W to R/O) and (2) the time to map large memory regions as
Gernot mentioned its for providing a consistent snapshot of user memory.
So just to make sure the current implementation for that is the optimal
remap (modify paging structure, clean cache, invalidate tlb), correct?

@Gernot, right, per our discussion, we only discussed out a bulk mapping
operation (mapping from other processes into the root process) but I was
not sure about locking (which is remapping in this case). Thank you for


On Mon, May 1, 2017 at 10:18 PM, <Gernot.Heiser at data61.csiro.au> wrote:

> On 2 May 2017, at 3:21 , Norrathep Rattanavipanon <nrattana at uci.edu>
> wrote:
> 2) If my understanding in 1) is correct, the remap function only takes 1
> cap at a time.
> So if I want to modify access rights of many pages, do I have to call the
> remap function multiple times?
> Or is there a more efficient way to do so?
> Hi Oak,
> As we discussed in person, this is a known issue of our API, and I have
> presently a student doing some evaluations. I have your use case in mind
> when talking to the student – for everyone else’s benefit, this is about a
> consistent shapshot of user memory for doing remote attestation.
> I would be interested in other use cases for a bulk re-mapping operation.
> I suspect that there are use cases where this might be a bottleneck, but it
> would be good to identify specific cases of enough significance to consider
> an API change. Certainly there won’t be a change if we don’t have
> convincing use cases.
> Gernot

Norrathep (Oak) Rattanavipanon
M.S. in Computer Science
University of California - Irvine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sel4.systems/pipermail/devel/attachments/20170501/1ae91e38/attachment.html>

More information about the Devel mailing list