[seL4] Change Access Right to Memory Pages

Norrathep Rattanavipanon nrattana at uci.edu
Thu May 4 12:43:29 AEST 2017


Actually, we want to try various methods to provide a consistent snapshot
of memory.

One method is to perform a bulk reduction in access rights of a lot of
(mapped) memory pages. Then, compute a hash on those pages. After that, we
increase the access rights back to the original (or R/W).

In the real implementation, we would like to handle when a legitimate page
fault happens (e.g. when another authorized thread tries to write into that
page while the page is being locked). Then, we have to increase access
rights and do copy-on-write-like operations on that page.

Oak

On Tue, May 2, 2017 at 9:22 PM, <Kevin.Elphinstone at data61.csiro.au> wrote:

> Just put up a straw man to potentially correct my understanding.
>
>
>
> I interpret this conversation as desiring a primitive to perform a bulk
> reduction in access rights of range page table entries of an address space
> – something that seems relatively straight forward – ignoring
> atomicity/WCET issues.
>
>
>
> What is not as straightforward is increasing access rights as appropriate
> authority needs to be presented somehow. If R/O -> R/W is page fault
> driven, e.g. for copy-on-write-like implementations, then that is
> relatively simple.
>
>
>
> -          Kevin
>
>
>
> *From:* Devel [mailto:devel-bounces at sel4.systems] *On Behalf Of *Norrathep
> Rattanavipanon
> *Sent:* Tuesday, 2 May 2017 4:07 PM
> *To:* Heiser, Gernot (Data61, Kensington NSW) <
> Gernot.Heiser at data61.csiro.au>
> *Cc:* devel at sel4.systems
> *Subject:* Re: [seL4] Change Access Right to Memory Pages
>
>
>
> Yes, you are absolutely right about that. I think it would be good to
> include the map time (even though called it once) for completeness :).
>
>
>
> On Mon, May 1, 2017 at 10:36 PM, <Gernot.Heiser at data61.csiro.au> wrote:
>
> Hi Oak,
>
>
>
> My understanding is that in your use case, the map is a one-off and
> therefore not performance-critical, while the re-map needs to be done on
> each snapshot and therefore is performance-critical.
>
>
>
> I hope the student gets to evaluate alternative implementation so we can
> see how much benefit bulk operations would provide.
>
>
>
> Gernot
>
>
>
> On 2 May 2017, at 15:32 , Norrathep Rattanavipanon <nrattana at uci.edu>
> wrote:
>
>
>
> 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
> confirming.
>
>
>
> Best,
>
> Oak
>
>
>
> 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
>
>
>
>
>
>
>
> --
>
> Norrathep (Oak) Rattanavipanon
>
> M.S. in Computer Science
>
> University of California - Irvine
>



-- 
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/20170503/fa248639/attachment.html>


More information about the Devel mailing list