Hi Utkarsh, On Sat, Mar 14, 2020 at 12:05 PM Utkarsh Rai <utkarsh.ra...@gmail.com> wrote: > > 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. > > Also, it would be very kind of you if you could help me with the previous > message on this thread. > > On Wed, Mar 11, 2020 at 8:34 AM Utkarsh Rai <utkarsh.ra...@gmail.com> wrote: >> >> Before specifying the interface I want to take your kind feedback on what >> all things would need to be done in the interface. >> >> By looking into the MMU description of ARM and x86, according to me, the >> implementation would have to be done in two levels- >> >> 1. The architecture-specific part, wherein I will have to initialize the >> MMU(already implemented for ARM), TLB management and exception handling.
Yes. This is done simply in a few ports where needed, usually just to setup a 1:1 VA-PA mapping. >> 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. >> I think Peter's advice is sound. We have a rough version of mmap implemented. It has a few problems and isn't completely functional for all use cases. The main question to consider as we move forward is whether to allow n:1 VA-PA mappings, which implies a non-linear address space. I think you will need to do some research about that topic. I don't think it is a great idea though, since AFAIK it requires an MMU to implement such mappings so if there is just an MPU then things may break (or work in weird ways). >> >> >> >> On Mon, Mar 9, 2020 at 1:47 AM <dufa...@hda.com> wrote: >>> >>> >>> >>> > On Mar 8, 2020, at 15:28 , dufa...@hda.com wrote: >>> > >>> > I have not gone through this thread as thoroughly as I should. Yet, I >>> > will still jump in. >>> > >>> > The stack protectin mechanism should be done in a POSIX compliant way >>> > without defining any extensions. >>> > >>> > 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. >>> > >>> > 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. >>> > >>> > I'd like to see: >>> > >>> > - The ability of each thread to specify a protected stack. >>> > - A protected thread's stack memory region shall be unavailable to other >>> > threads unless it is in a shared memory region. >>> > -- 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. >>> >>> 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. >>> >>> 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. >>> >>> Peter >>> ----------------- >>> Peter Dufault >>> HD Associates, Inc. Software and System Engineering >>> >>> This email is delivered through the public internet using protocols subject >>> to interception and tampering. >>> _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
