<div dir="ltr">I am in the middle of drafting the proposal for the memory protection project and specifying the interface, one of the things I would like to take to your feedback on is what are the functionalities that would be provided to the users, as some of the architectures provide a lot of support that others don't, should we keep that to a minimum or go with the maximum options. For example, ARM provides 4kb, 16kb, and 64kb page granules whereas others don't so either the users can be provided with the option of accessing other stacks in granules of various sizes or a common-minimum of 4kb. <div><br><div>Also, it would be very kind of you if you could help me with the previous message on this thread.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 11, 2020 at 8:34 AM Utkarsh Rai <<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"> Before specifying the interface I want to take your kind feedback on what all things would need to be done in the interface.<div><br><div> By looking into the MMU description of ARM and x86, according to me, the implementation would have to be done in two levels-<div><br></div><div>1. The architecture-specific part, wherein I will have to initialize the MMU(already implemented for ARM), TLB management and exception handling.</div><div>2. The generalization part, wherein I will need to manage the thread stacks, their access permissions. Each stack should have a data structure associated with it that has the permission flags, starting address and other relevant information. For increased robustness of the thread stacks, every time a context switch takes place we will have to set up the page tables, TLBs to map the address of the executing thread as well as that of the threads it has the permission to access.</div><div><br></div><div><br></div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 9, 2020 at 1:47 AM <<a href="mailto:dufault@hda.com" target="_blank">dufault@hda.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Mar 8, 2020, at 15:28 , <a href="mailto:dufault@hda.com" target="_blank">dufault@hda.com</a> wrote:<br>
> <br>
> I have not gone through this thread as thoroughly as I should.  Yet, I will still jump in.<br>
> <br>
> The stack protectin mechanism should be done in a POSIX compliant way without defining any extensions.<br>
> <br>
> When threads have protected stack areas that must be shared those regions should be shared using an "mmap" interface. That is POSIX compliant, and will require extra effort to establish the sharing of stack-based memory regions.<br>
> <br>
> My two minute analysis of "thread pools" is that protected stacks in RTEMS should be implemented without that.  Applications that want protected stacks should have the discipline of explicitly requesting access to regions of memory that are in another threads stack.  The value of protected stacks will not be cost free.<br>
> <br>
> I'd like to see:<br>
> <br>
> - The ability of each thread to specify a protected stack.<br>
> - A protected thread's stack memory region shall be unavailable to other threads unless it is in a shared memory region.<br>
> -- I won't define the granularity of what the previous point means.  In most implementations, it probably means that if "task2" has access to memory in the "task1" stack via mmap then it can probably stomp all over any part of task1s stack, it probably implies that the task1 stack memory is left accessible when task2 is running instead of being unmapped.<br>
<br>
In the Olden Days I worked on an architecture (Alliant mini supercomputers) where the stack wasn't in shared memory.  It took a little bit of getting used to, but not much.  In that architecture you just couldn't share the stack, no hope to "mmap" anything.<br>
<br>
We should define the goal of protected stacks.  My goal is increased robustness at the expense of additional application setup complexity, but the application setup should be 100% POSIX compliant.<br>
<br>
Peter<br>
-----------------<br>
Peter Dufault<br>
HD Associates, Inc.      Software and System Engineering<br>
<br>
This email is delivered through the public internet using protocols subject to interception and tampering.<br>
<br>
</blockquote></div>
</blockquote></div>