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

[Utkarsh Rai]

On Sat, May 16, 2020 at 9:16 PM Joel Sherrill  wrote:

>
>
> On Sat, May 16, 2020 at 10:14 AM Gedare Bloom  wrote:
>
>> 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 
>> wrote:
>>
>>>
>>>
>>> On Thu, May 14, 2020 at 10:23 AM Sebastian Huber <
>>> sebastian.hu...@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
 > ,
 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 .
>>>
 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.
>>>
>>>
> I think Sebastian is asking exactly what I did. What are the processor
> (specific CPU) requirements to support thread stack protection?
>

For thread stack protection the processor should have the option of paging
along with appropriate 'access bits' setting. Both RISC-V and ARMv7-A (the
ones that I will be focusing on my project) have the option of defining
pages of 4KiB size with appropriate access bits.


>
> For example, to be effective, I imagine a 1MB granularity might be
> sufficient to protect code versus data/bss. But it is likely insufficient
> to protect thread stacks.
>
> Similarly, a processor with a limited number of "protection areas" would
> be unsuitable as a basis for implementing thread stack protection. Here I
> am thinking of the PowerPC with a handful of TLB registers. You would have
> to turn on paging.
>

I agree, most of the processors have protection regions between 8 to 16 and
in some cases as less as 4. For stack protection paging with each page of
size 4KiB, as it is applicable for processors with mpu or mmu and is
optimal, in the sense that we would have appropriate number and size of
pages for thread stacks, is the best option.


> This is the general guidance that needs to be provided so anyone can
> evaluate how much protection they really can have on their target.
>
> --joel
>
>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Gedare Bloom]

On Mon, May 18, 2020 at 4:31 AM Utkarsh Rai  wrote:
>
>
>
>
> On Sat, May 16, 2020 at 9:16 PM Joel Sherrill  wrote:
>>
>>
>>
>> On Sat, May 16, 2020 at 10:14 AM Gedare Bloom  wrote:
>>>
>>> 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  wrote:



 On Thu, May 14, 2020 at 10:23 AM Sebastian Huber 
  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
> > , 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.
>
> 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.
>>
>>
>> I think Sebastian is asking exactly what I did. What are the processor 
>> (specific CPU) requirements to support thread stack protection?
>
>
> For thread stack protection the processor should have the option of paging 
> along with appropriate 'access bits' setting. Both RISC-V and ARMv7-A (the 
> ones that I will be focusing on my project) have the option of defining pages 
> of 4KiB size with appropriate access bits.
>
>>
>>
>> For example, to be effective, I imagine a 1MB granularity might be 
>> sufficient to protect code versus data/bss. But it is likely insufficient to 
>> protect thread stacks.
>>
>> Similarly, a processor with a limited number of "protection areas" would be 
>> unsuitable as a basis for implementing thread stack protection. Here I am 
>> thinking of the PowerPC with a handful of TLB registers. You would have to 
>> turn on paging.
>
>
> I agree, most of the processors have protection regions between 8 to 16 and 
> in some cases as less as 4. For stack protection paging with each page of 
> size 4KiB, as it is applicable for processors with mpu or mmu and is optimal, 
> in the sense that we would have appropriate number and size of pages for 
> thread stacks, is the best option.
>

We should have a clear understanding of the design requirements
brefore we can make such a statement about "optimal" and "best".

The proposal has some good ideas in it, but I think the project has
some implied expectations or assumptions, on both your side and from
mentors/stakeholders. Here are some ideas that should start to hint at
requirements. Maybe you can propose some design requirements. I'm not
too good at writing requirements myself, but here goes:
1. Memory protection is optional. The default is no memory protection.
2. The basic protection isolates the text, rodata, and rwdata from
each other. There is no notion of task-specific protection domains,
and tasks should not incur any additional overhead due to this
protection.
3. The advanced protection strongly isolates all tasks' stacks.
Sharing is done explicitly via POSIX/RTEMS APIs, and the heap and
executive (kernel/RTEMS) memory are globally shared. A task shall only
incur additional overhead in context switches and the first access to
a protected region (other task's stack it shares) after a context
switch.

I'm sure there are more you can dr