Hello,
I have some questions about how to change access rights in seL4. (I'm using native seL4, not camkes)
1) Currently, I'm using seL4_ARCH_Page_Remap to change an access right (from R/W to R/O) to a specific page (of other processes) at run-time. I'm doing as follows:
seL4_CPtr frame = vspace_get_cap(&(p.vspace), p.thread.stack_top-1); // only for the stack int error = seL4_ARCH_Page_Remap(frame, ppd.cptr, seL4_CanRead, seL4_ARCH_Default_VMAttributes);
Am I doing it correctly? The code seems to work fine for me but I just want to double check.
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?
3) I am also curious how the kernel handles the remap function. Does it simply flip/change some bits? Or does it involve page-related operations as well? e.g. unmap that page first and then remap the same region with a new access right? I guess it should be the former but I need to be sure about that.
Thank you,
Oak
Hi Oak,
1. Looks fine to me. You can test the permissions yourself though by attempting to write to that page before and after the Remap 2. Unfortunately no, there is no more efficient way in seL4. Only suggestion I can make is use larger pages where possible 3. Since you have not specified I will assume, for this explanation, that you are using the ARM IMX.6 Sabre platform. On ARM you can never just 'flip some bits' to manipulate any paging structures, as information needs to be propagated out of the L1 cache and TLB entries invalidated. I'm not sure what you mean by 'page-related operation', you're doing a remap, that is a page related operation is it not? I also cannot see how the implementation of remap in any way matters to you, the observable difference between the optimal remap (modify paging structure, clean cache, invalidate tlb) used by seL4 and unmap (modify paging structure, clean cache, invalidate tlb) then map (modify paging structure, clean cache) is a redundant memory write and cache clean, which aside from impacting execution time have no visible effects as the final memory, cache state and TLB state is the same.
Adrian
On Tue 02-May-2017 3:21 AM, Norrathep Rattanavipanon wrote: Hello,
I have some questions about how to change access rights in seL4. (I'm using native seL4, not camkes)
1) Currently, I'm using seL4_ARCH_Page_Remap to change an access right (from R/W to R/O) to a specific page (of other processes) at run-time. I'm doing as follows:
seL4_CPtr frame = vspace_get_cap(&(p.vspace), p.thread.stack_top-1); // only for the stack int error = seL4_ARCH_Page_Remap(frame, ppd.cptr, seL4_CanRead, seL4_ARCH_Default_VMAttributes);
Am I doing it correctly? The code seems to work fine for me but I just want to double check.
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?
3) I am also curious how the kernel handles the remap function. Does it simply flip/change some bits? Or does it involve page-related operations as well? e.g. unmap that page first and then remap the same region with a new access right? I guess it should be the former but I need to be sure about that.
Thank you,
Oak
-- Norrathep (Oak) Rattanavipanon M.S. in Computer Science University of California - Irvine
_______________________________________________ Devel mailing list Devel@sel4.systemsmailto:Devel@sel4.systems https://sel4.systems/lists/listinfo/devel
On 2 May 2017, at 3:21 , Norrathep Rattanavipanon <nrattana@uci.edumailto:nrattana@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
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@data61.csiro.au wrote:
On 2 May 2017, at 3:21 , Norrathep Rattanavipanon nrattana@uci.edu wrote:
- 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
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@uci.edumailto:nrattana@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@data61.csiro.aumailto:Gernot.Heiser@data61.csiro.au> wrote: On 2 May 2017, at 3:21 , Norrathep Rattanavipanon <nrattana@uci.edumailto:nrattana@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
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@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@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@data61.csiro.au wrote:
On 2 May 2017, at 3:21 , Norrathep Rattanavipanon nrattana@uci.edu wrote:
- 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
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@sel4.systems] On Behalf Of Norrathep Rattanavipanon Sent: Tuesday, 2 May 2017 4:07 PM To: Heiser, Gernot (Data61, Kensington NSW) Gernot.Heiser@data61.csiro.au Cc: devel@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@data61.csiro.aumailto:Gernot.Heiser@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@uci.edumailto:nrattana@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@data61.csiro.aumailto:Gernot.Heiser@data61.csiro.au> wrote: On 2 May 2017, at 3:21 , Norrathep Rattanavipanon <nrattana@uci.edumailto:nrattana@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
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@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@sel4.systems] *On Behalf Of *Norrathep Rattanavipanon *Sent:* Tuesday, 2 May 2017 4:07 PM *To:* Heiser, Gernot (Data61, Kensington NSW) < Gernot.Heiser@data61.csiro.au> *Cc:* devel@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@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@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@data61.csiro.au wrote:
On 2 May 2017, at 3:21 , Norrathep Rattanavipanon nrattana@uci.edu wrote:
- 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
-
Adrian.Danis＠data61.csiro.au -
Gernot.Heiser＠data61.csiro.au -
Kevin.Elphinstone＠data61.csiro.au -
Norrathep Rattanavipanon