Help on how to configure for user-defined memory protection support (GSoC 2020)

[Gedare Bloom]

Utkarsh,

What do you mean by "This would although mean that we would have page
tables of  1MB."

Check that you use plain text when inlining a reply, or at least that you
broke the reply format.

Gedare

On Fri, May 15, 2020, 6:04 PM Utkarsh Rai <utkarsh.rai60 at gmail.com> wrote:

>
>
> On Thu, May 14, 2020 at 10:23 AM Sebastian Huber <
> sebastian.huber at embedded-brains.de> wrote:
>
>> Hello Utkarsh Rai,
>>
>> On 13/05/2020 14:30, Utkarsh Rai wrote:
>> > Hello,
>> > My GSoC project,  providing thread stack protection support, has to be
>> > a user-configurable feature.
>> > My question is,  what would be the best way to implement this, my idea
>> > was to model it based on the existing system configuration
>> > <https://docs.rtems.org/branches/master/c-user/config/intro.html>, but
>> > Dr. Gedare pointed out that configuration is undergoing heavy changes
>> > and may look completely different in future releases. Kindly advise me
>> > as to what would be the best way to proceed.
>> before we start with an implementation. It would be good to define what
>> a thread stack protection support is supposed to do.
>
>
> The thread stack protection mechanism will protect against stack overflow
> errors and will completely isolate the thread stacks from each other.
> Sharing of thread stack will be possible only when the user makes explicit
> calls to do so. More details about this can be found in this thread
> <https://lists.rtems.org/pipermail/devel/2020-May/059768.html>.
>
>> Then there should
>> be a concept for systems with a Memory Protection Unit (MPU) and a
>> concept for systems with a Memory Management Unit (MMU). MMUs may
>> provide normal 4KiB Pages, large Pages (for example 1MiB) or something
>> more flexible. We should identify BSPs which should have support for
>> this. For each BSP should be a concept. Then we should think about how a
>> user can configure this feature.
>
> For memory protection will have a 1:1 VA-PA address translation that means
>> a 4KiB page size will be set for both the MPU and MMU, a 1:1 mapping will
>> ensure we will have to do lesser page table walks.This would although mean
>> that we would have page tables of  1MB. I will be first providing the
>> support for Armv7 based BSPs (RPi , BBB, etc. have MMU support) then when I
>> have a working example I will move on to provide the support for RISC-V.
>> which has MPU support.
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200516/b41c1213/attachment.html>