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

[Gedare Bloom]

On Thu, May 28, 2020 at 6:24 PM Utkarsh Rai  wrote:
>
>
>
>
> On Wed, May 27, 2020 at 8:29 PM Gedare Bloom  wrote:
>>
>> On Tue, May 26, 2020 at 6:12 PM Utkarsh Rai  wrote:
>> >
>> >
>> >
>> > On Mon, May 25, 2020 at 9:32 PM Gedare Bloom  wrote:
>> >>
>> >> On Mon, May 25, 2020 at 5:39 AM Utkarsh Rai  
>> >> wrote:
>> >> >
>> >> >
>> >> > On Fri, May 22, 2020, at 10:59 AM Gedare Bloom  wrote:
>> >> >>
>> >> >> >  This means that our low-level design for providing thread stack 
>> >> >> > protection may look something like this:-
>> >> >> >
>> >> >> > 1. For MPU based processors, the number of protected stacks will 
>> >> >> > depend on the number of protection domains i.e. for MPUs with 8 
>> >> >> > protection domains we can have 7 protected stacks ( 1 of the region 
>> >> >> > will be assigned for global data). For MMU based system we will have 
>> >> >> > a section (a page of size 1MB) for global data and task address 
>> >> >> > space will be divided into smaller pages, page sizes will be decided 
>> >> >> > by keeping in mind the number of TLB entries, in a manner I have 
>> >> >> > described above in the thread.
>> >> >> >
>> >> >> There is value to defining a few of the global regions. I'll assume
>> >> >> R/W/X permissions. Then code (.text) should be R/X. read-only data
>> >> >> sections should be grouped together and made R. Data sections should
>> >> >> be RW. And then stacks should be added to the end. The linker scripts
>> >> >> should be used to group the related sections together. I think some
>> >> >> ARM BSPs do some of this already.  That seems like a minimally useful
>> >> >> configuration for most users that would care, they want to have also
>> >> >> protection of code from accidental overwrite, and probably data too,
>> >> >> and non-executable data in general. You also may have to consider a
>> >> >> few more permission complications (shared/cacheable) depending on the
>> >> >> hardware.
>> >> >
>> >> >
>> >> > The low-level mmu implementation for ARMv7 BSPS has an 
>> >> > 'ARMV7_CP15_START_DEFAULT_SECTIONS' which lists out various regions 
>> >> > with appropriate permissions and then are grouped by a linker script. 
>> >> > This should be the standard way of handling the placement of statically 
>> >> > allocated regions.
>> >> >
>> >> >> >  2. The protection, size, page table, and sharing attributes of each 
>> >> >> > created thread will be tracked.
>> >> >> >
>> >> >> I'd rather we not be calling this a page table. MPU-based systems
>> >> >> don't have a notion of page table. But maybe it is OK as long as we
>> >> >> understand that you mean the data structure responsible for mapping
>> >> >> out the address space. I'm not sure what you mean by size, unless you
>> >> >> refer to that thread's stack.
>> >> >>
>> >> >> >  3. At every context switch, these attributes will be updated, the 
>> >> >> > static-global regions will be assigned a global ASID and will not 
>> >> >> > change during the switch only the protected regions will be updated.
>> >> >> >
>> >> >> Yes, assuming the hardware supports ASIDs and a global attribute.
>> >> >>
>> >> >> I don't know if you will be able to pin the global entries in
>> >> >> hardware. You'll want to keep an eye out for that. If not, you might
>> >> >> need to do something in software to ensure they don't get evicted
>> >> >> (e.g., touch them all before finishing a context switch assuming LRU
>> >> >> replacement).
>> >> >>
>> >> >> >  4. Whenever we share stacks, the page table entries of the shared 
>> >> >> > stack, with the access bits as specified by the mmap/shm high-level 
>> >> >> > APIs will be installed to the current thread. This is different from 
>> >> >> > simply providing the page table base address of the shared 
>> >> >> > thread-stack ( what if the user wants to make the shared thread only 
>> >> >> > readable from another thread while the 'original' thread is r/w 
>> >> >> > enabled?) We will also have to update the TLB by installing the 
>> >> >> > shared regions while the global regions remain untouched.
>> >> >> >
>> >> >>
>> >> >> Correct. I think we need to make a design decision whether a stack can
>> >> >> exceed one page. It will simplify things if we can assume that, but it
>> >> >> may limit applications unnecessarily. Have to think on that.
>> >> >
>> >> >
>> >> > If we go with the above assumption, we will need to increase the size 
>> >> > of the page i.e. pages of 16Kib or 64Kib. Most of the applications 
>> >> > won't require stacks of this size and will result in wasted memory for 
>> >> > each thread. I think it would be better if we have multiple pages, as 
>> >> > most of the applications will have stacks that may fit in a single 4KiB 
>> >> > page anyway.
>> >> >
>> >>
>> >> I mis-typed. I meant I think we can assume stacks fit in one page. It
>> >> would be impossible to deal with otherwise.
>> >>
>> >> >>
>> >> >> The "page table base address" points to the entire structure that maps
>> >> >> out a t

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

[Utkarsh Rai]

On Wed, May 27, 2020 at 8:29 PM Gedare Bloom  wrote:

> On Tue, May 26, 2020 at 6:12 PM Utkarsh Rai 
> wrote:
> >
> >
> >
> > On Mon, May 25, 2020 at 9:32 PM Gedare Bloom  wrote:
> >>
> >> On Mon, May 25, 2020 at 5:39 AM Utkarsh Rai 
> wrote:
> >> >
> >> >
> >> > On Fri, May 22, 2020, at 10:59 AM Gedare Bloom 
> wrote:
> >> >>
> >> >> >  This means that our low-level design for providing thread stack
> protection may look something like this:-
> >> >> >
> >> >> > 1. For MPU based processors, the number of protected stacks will
> depend on the number of protection domains i.e. for MPUs with 8 protection
> domains we can have 7 protected stacks ( 1 of the region will be assigned
> for global data). For MMU based system we will have a section (a page of
> size 1MB) for global data and task address space will be divided into
> smaller pages, page sizes will be decided by keeping in mind the number of
> TLB entries, in a manner I have described above in the thread.
> >> >> >
> >> >> There is value to defining a few of the global regions. I'll assume
> >> >> R/W/X permissions. Then code (.text) should be R/X. read-only data
> >> >> sections should be grouped together and made R. Data sections should
> >> >> be RW. And then stacks should be added to the end. The linker scripts
> >> >> should be used to group the related sections together. I think some
> >> >> ARM BSPs do some of this already.  That seems like a minimally useful
> >> >> configuration for most users that would care, they want to have also
> >> >> protection of code from accidental overwrite, and probably data too,
> >> >> and non-executable data in general. You also may have to consider a
> >> >> few more permission complications (shared/cacheable) depending on the
> >> >> hardware.
> >> >
> >> >
> >> > The low-level mmu implementation for ARMv7 BSPS has an
> 'ARMV7_CP15_START_DEFAULT_SECTIONS' which lists out various regions with
> appropriate permissions and then are grouped by a linker script. This
> should be the standard way of handling the placement of statically
> allocated regions.
> >> >
> >> >> >  2. The protection, size, page table, and sharing attributes of
> each created thread will be tracked.
> >> >> >
> >> >> I'd rather we not be calling this a page table. MPU-based systems
> >> >> don't have a notion of page table. But maybe it is OK as long as we
> >> >> understand that you mean the data structure responsible for mapping
> >> >> out the address space. I'm not sure what you mean by size, unless you
> >> >> refer to that thread's stack.
> >> >>
> >> >> >  3. At every context switch, these attributes will be updated, the
> static-global regions will be assigned a global ASID and will not change
> during the switch only the protected regions will be updated.
> >> >> >
> >> >> Yes, assuming the hardware supports ASIDs and a global attribute.
> >> >>
> >> >> I don't know if you will be able to pin the global entries in
> >> >> hardware. You'll want to keep an eye out for that. If not, you might
> >> >> need to do something in software to ensure they don't get evicted
> >> >> (e.g., touch them all before finishing a context switch assuming LRU
> >> >> replacement).
> >> >>
> >> >> >  4. Whenever we share stacks, the page table entries of the shared
> stack, with the access bits as specified by the mmap/shm high-level APIs
> will be installed to the current thread. This is different from simply
> providing the page table base address of the shared thread-stack ( what if
> the user wants to make the shared thread only readable from another thread
> while the 'original' thread is r/w enabled?) We will also have to update
> the TLB by installing the shared regions while the global regions remain
> untouched.
> >> >> >
> >> >>
> >> >> Correct. I think we need to make a design decision whether a stack
> can
> >> >> exceed one page. It will simplify things if we can assume that, but
> it
> >> >> may limit applications unnecessarily. Have to think on that.
> >> >
> >> >
> >> > If we go with the above assumption, we will need to increase the size
> of the page i.e. pages of 16Kib or 64Kib. Most of the applications won't
> require stacks of this size and will result in wasted memory for each
> thread. I think it would be better if we have multiple pages, as most of
> the applications will have stacks that may fit in a single 4KiB page anyway.
> >> >
> >>
> >> I mis-typed. I meant I think we can assume stacks fit in one page. It
> >> would be impossible to deal with otherwise.
> >>
> >> >>
> >> >> The "page table base address" points to the entire structure that
> maps
> >> >> out a thread's address space, so you'd have to walk it to find the
> >> >> entry/entries for its stack. So, definitely not something you'd want
> >> >> to do.
> >> >>
> >> >> The shm/mmap should convey the privileges to the requesting thread
> >> >> asking to share. This will result in adding the shared entry/entries
> >> >> to that thread's address space, with the appropriat

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

[Gedare Bloom]

On Tue, May 26, 2020 at 6:12 PM Utkarsh Rai  wrote:
>
>
>
> On Mon, May 25, 2020 at 9:32 PM Gedare Bloom  wrote:
>>
>> On Mon, May 25, 2020 at 5:39 AM Utkarsh Rai  wrote:
>> >
>> >
>> > On Fri, May 22, 2020, at 10:59 AM Gedare Bloom  wrote:
>> >>
>> >> >  This means that our low-level design for providing thread stack 
>> >> > protection may look something like this:-
>> >> >
>> >> > 1. For MPU based processors, the number of protected stacks will depend 
>> >> > on the number of protection domains i.e. for MPUs with 8 protection 
>> >> > domains we can have 7 protected stacks ( 1 of the region will be 
>> >> > assigned for global data). For MMU based system we will have a section 
>> >> > (a page of size 1MB) for global data and task address space will be 
>> >> > divided into smaller pages, page sizes will be decided by keeping in 
>> >> > mind the number of TLB entries, in a manner I have described above in 
>> >> > the thread.
>> >> >
>> >> There is value to defining a few of the global regions. I'll assume
>> >> R/W/X permissions. Then code (.text) should be R/X. read-only data
>> >> sections should be grouped together and made R. Data sections should
>> >> be RW. And then stacks should be added to the end. The linker scripts
>> >> should be used to group the related sections together. I think some
>> >> ARM BSPs do some of this already.  That seems like a minimally useful
>> >> configuration for most users that would care, they want to have also
>> >> protection of code from accidental overwrite, and probably data too,
>> >> and non-executable data in general. You also may have to consider a
>> >> few more permission complications (shared/cacheable) depending on the
>> >> hardware.
>> >
>> >
>> > The low-level mmu implementation for ARMv7 BSPS has an 
>> > 'ARMV7_CP15_START_DEFAULT_SECTIONS' which lists out various regions with 
>> > appropriate permissions and then are grouped by a linker script. This 
>> > should be the standard way of handling the placement of statically 
>> > allocated regions.
>> >
>> >> >  2. The protection, size, page table, and sharing attributes of each 
>> >> > created thread will be tracked.
>> >> >
>> >> I'd rather we not be calling this a page table. MPU-based systems
>> >> don't have a notion of page table. But maybe it is OK as long as we
>> >> understand that you mean the data structure responsible for mapping
>> >> out the address space. I'm not sure what you mean by size, unless you
>> >> refer to that thread's stack.
>> >>
>> >> >  3. At every context switch, these attributes will be updated, the 
>> >> > static-global regions will be assigned a global ASID and will not 
>> >> > change during the switch only the protected regions will be updated.
>> >> >
>> >> Yes, assuming the hardware supports ASIDs and a global attribute.
>> >>
>> >> I don't know if you will be able to pin the global entries in
>> >> hardware. You'll want to keep an eye out for that. If not, you might
>> >> need to do something in software to ensure they don't get evicted
>> >> (e.g., touch them all before finishing a context switch assuming LRU
>> >> replacement).
>> >>
>> >> >  4. Whenever we share stacks, the page table entries of the shared 
>> >> > stack, with the access bits as specified by the mmap/shm high-level 
>> >> > APIs will be installed to the current thread. This is different from 
>> >> > simply providing the page table base address of the shared thread-stack 
>> >> > ( what if the user wants to make the shared thread only readable from 
>> >> > another thread while the 'original' thread is r/w enabled?) We will 
>> >> > also have to update the TLB by installing the shared regions while the 
>> >> > global regions remain untouched.
>> >> >
>> >>
>> >> Correct. I think we need to make a design decision whether a stack can
>> >> exceed one page. It will simplify things if we can assume that, but it
>> >> may limit applications unnecessarily. Have to think on that.
>> >
>> >
>> > If we go with the above assumption, we will need to increase the size of 
>> > the page i.e. pages of 16Kib or 64Kib. Most of the applications won't 
>> > require stacks of this size and will result in wasted memory for each 
>> > thread. I think it would be better if we have multiple pages, as most of 
>> > the applications will have stacks that may fit in a single 4KiB page 
>> > anyway.
>> >
>>
>> I mis-typed. I meant I think we can assume stacks fit in one page. It
>> would be impossible to deal with otherwise.
>>
>> >>
>> >> The "page table base address" points to the entire structure that maps
>> >> out a thread's address space, so you'd have to walk it to find the
>> >> entry/entries for its stack. So, definitely not something you'd want
>> >> to do.
>> >>
>> >> The shm/mmap should convey the privileges to the requesting thread
>> >> asking to share. This will result in adding the shared entry/entries
>> >> to that thread's address space, with the appropriately set
>> >> permissions. So, if the entr

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

[Utkarsh Rai]

On Mon, May 25, 2020 at 9:32 PM Gedare Bloom  wrote:

> On Mon, May 25, 2020 at 5:39 AM Utkarsh Rai 
> wrote:
> >
> >
> > On Fri, May 22, 2020, at 10:59 AM Gedare Bloom  wrote:
> >>
> >> >  This means that our low-level design for providing thread stack
> protection may look something like this:-
> >> >
> >> > 1. For MPU based processors, the number of protected stacks will
> depend on the number of protection domains i.e. for MPUs with 8 protection
> domains we can have 7 protected stacks ( 1 of the region will be assigned
> for global data). For MMU based system we will have a section (a page of
> size 1MB) for global data and task address space will be divided into
> smaller pages, page sizes will be decided by keeping in mind the number of
> TLB entries, in a manner I have described above in the thread.
> >> >
> >> There is value to defining a few of the global regions. I'll assume
> >> R/W/X permissions. Then code (.text) should be R/X. read-only data
> >> sections should be grouped together and made R. Data sections should
> >> be RW. And then stacks should be added to the end. The linker scripts
> >> should be used to group the related sections together. I think some
> >> ARM BSPs do some of this already.  That seems like a minimally useful
> >> configuration for most users that would care, they want to have also
> >> protection of code from accidental overwrite, and probably data too,
> >> and non-executable data in general. You also may have to consider a
> >> few more permission complications (shared/cacheable) depending on the
> >> hardware.
> >
> >
> > The low-level mmu implementation for ARMv7 BSPS has an
> 'ARMV7_CP15_START_DEFAULT_SECTIONS' which lists out various regions with
> appropriate permissions and then are grouped by a linker script. This
> should be the standard way of handling the placement of statically
> allocated regions.
> >
> >> >  2. The protection, size, page table, and sharing attributes of each
> created thread will be tracked.
> >> >
> >> I'd rather we not be calling this a page table. MPU-based systems
> >> don't have a notion of page table. But maybe it is OK as long as we
> >> understand that you mean the data structure responsible for mapping
> >> out the address space. I'm not sure what you mean by size, unless you
> >> refer to that thread's stack.
> >>
> >> >  3. At every context switch, these attributes will be updated, the
> static-global regions will be assigned a global ASID and will not change
> during the switch only the protected regions will be updated.
> >> >
> >> Yes, assuming the hardware supports ASIDs and a global attribute.
> >>
> >> I don't know if you will be able to pin the global entries in
> >> hardware. You'll want to keep an eye out for that. If not, you might
> >> need to do something in software to ensure they don't get evicted
> >> (e.g., touch them all before finishing a context switch assuming LRU
> >> replacement).
> >>
> >> >  4. Whenever we share stacks, the page table entries of the shared
> stack, with the access bits as specified by the mmap/shm high-level APIs
> will be installed to the current thread. This is different from simply
> providing the page table base address of the shared thread-stack ( what if
> the user wants to make the shared thread only readable from another thread
> while the 'original' thread is r/w enabled?) We will also have to update
> the TLB by installing the shared regions while the global regions remain
> untouched.
> >> >
> >>
> >> Correct. I think we need to make a design decision whether a stack can
> >> exceed one page. It will simplify things if we can assume that, but it
> >> may limit applications unnecessarily. Have to think on that.
> >
> >
> > If we go with the above assumption, we will need to increase the size of
> the page i.e. pages of 16Kib or 64Kib. Most of the applications won't
> require stacks of this size and will result in wasted memory for each
> thread. I think it would be better if we have multiple pages, as most of
> the applications will have stacks that may fit in a single 4KiB page anyway.
> >
>
> I mis-typed. I meant I think we can assume stacks fit in one page. It
> would be impossible to deal with otherwise.
>
> >>
> >> The "page table base address" points to the entire structure that maps
> >> out a thread's address space, so you'd have to walk it to find the
> >> entry/entries for its stack. So, definitely not something you'd want
> >> to do.
> >>
> >> The shm/mmap should convey the privileges to the requesting thread
> >> asking to share. This will result in adding the shared entry/entries
> >> to that thread's address space, with the appropriately set
> >> permissions. So, if the entry is created with read-only permission,
> >> then that is how the thread will be sharing. The original thread's
> >> entry should not be modified by the addition of an entry in another
> >> thread for the same memory region.
> >>
> >> I lean toward thinking it is better to always pay for the

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

[Gedare Bloom]

On Mon, May 25, 2020 at 5:39 AM Utkarsh Rai  wrote:
>
>
> On Fri, May 22, 2020, at 10:59 AM Gedare Bloom  wrote:
>>
>> >  This means that our low-level design for providing thread stack 
>> > protection may look something like this:-
>> >
>> > 1. For MPU based processors, the number of protected stacks will depend on 
>> > the number of protection domains i.e. for MPUs with 8 protection domains 
>> > we can have 7 protected stacks ( 1 of the region will be assigned for 
>> > global data). For MMU based system we will have a section (a page of size 
>> > 1MB) for global data and task address space will be divided into smaller 
>> > pages, page sizes will be decided by keeping in mind the number of TLB 
>> > entries, in a manner I have described above in the thread.
>> >
>> There is value to defining a few of the global regions. I'll assume
>> R/W/X permissions. Then code (.text) should be R/X. read-only data
>> sections should be grouped together and made R. Data sections should
>> be RW. And then stacks should be added to the end. The linker scripts
>> should be used to group the related sections together. I think some
>> ARM BSPs do some of this already.  That seems like a minimally useful
>> configuration for most users that would care, they want to have also
>> protection of code from accidental overwrite, and probably data too,
>> and non-executable data in general. You also may have to consider a
>> few more permission complications (shared/cacheable) depending on the
>> hardware.
>
>
> The low-level mmu implementation for ARMv7 BSPS has an 
> 'ARMV7_CP15_START_DEFAULT_SECTIONS' which lists out various regions with 
> appropriate permissions and then are grouped by a linker script. This should 
> be the standard way of handling the placement of statically allocated regions.
>
>> >  2. The protection, size, page table, and sharing attributes of each 
>> > created thread will be tracked.
>> >
>> I'd rather we not be calling this a page table. MPU-based systems
>> don't have a notion of page table. But maybe it is OK as long as we
>> understand that you mean the data structure responsible for mapping
>> out the address space. I'm not sure what you mean by size, unless you
>> refer to that thread's stack.
>>
>> >  3. At every context switch, these attributes will be updated, the 
>> > static-global regions will be assigned a global ASID and will not change 
>> > during the switch only the protected regions will be updated.
>> >
>> Yes, assuming the hardware supports ASIDs and a global attribute.
>>
>> I don't know if you will be able to pin the global entries in
>> hardware. You'll want to keep an eye out for that. If not, you might
>> need to do something in software to ensure they don't get evicted
>> (e.g., touch them all before finishing a context switch assuming LRU
>> replacement).
>>
>> >  4. Whenever we share stacks, the page table entries of the shared stack, 
>> > with the access bits as specified by the mmap/shm high-level APIs will be 
>> > installed to the current thread. This is different from simply providing 
>> > the page table base address of the shared thread-stack ( what if the user 
>> > wants to make the shared thread only readable from another thread while 
>> > the 'original' thread is r/w enabled?) We will also have to update the TLB 
>> > by installing the shared regions while the global regions remain untouched.
>> >
>>
>> Correct. I think we need to make a design decision whether a stack can
>> exceed one page. It will simplify things if we can assume that, but it
>> may limit applications unnecessarily. Have to think on that.
>
>
> If we go with the above assumption, we will need to increase the size of the 
> page i.e. pages of 16Kib or 64Kib. Most of the applications won't require 
> stacks of this size and will result in wasted memory for each thread. I think 
> it would be better if we have multiple pages, as most of the applications 
> will have stacks that may fit in a single 4KiB page anyway.
>

I mis-typed. I meant I think we can assume stacks fit in one page. It
would be impossible to deal with otherwise.

>>
>> The "page table base address" points to the entire structure that maps
>> out a thread's address space, so you'd have to walk it to find the
>> entry/entries for its stack. So, definitely not something you'd want
>> to do.
>>
>> The shm/mmap should convey the privileges to the requesting thread
>> asking to share. This will result in adding the shared entry/entries
>> to that thread's address space, with the appropriately set
>> permissions. So, if the entry is created with read-only permission,
>> then that is how the thread will be sharing. The original thread's
>> entry should not be modified by the addition of an entry in another
>> thread for the same memory region.
>>
>> I lean toward thinking it is better to always pay for the TLB miss at
>> the context switch, which might mean synthesizing accesses to the
>> entries that might have been evicted in case

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

[Utkarsh Rai]

On Fri, May 22, 2020, at 10:59 AM Gedare Bloom  wrote:

> >  This means that our low-level design for providing thread stack
> protection may look something like this:-
> >
> > 1. For MPU based processors, the number of protected stacks will depend
> on the number of protection domains i.e. for MPUs with 8 protection domains
> we can have 7 protected stacks ( 1 of the region will be assigned for
> global data). For MMU based system we will have a section (a page of size
> 1MB) for global data and task address space will be divided into smaller
> pages, page sizes will be decided by keeping in mind the number of TLB
> entries, in a manner I have described above in the thread.
> >
> There is value to defining a few of the global regions. I'll assume
> R/W/X permissions. Then code (.text) should be R/X. read-only data
> sections should be grouped together and made R. Data sections should
> be RW. And then stacks should be added to the end. The linker scripts
> should be used to group the related sections together. I think some
> ARM BSPs do some of this already.  That seems like a minimally useful
> configuration for most users that would care, they want to have also
> protection of code from accidental overwrite, and probably data too,
> and non-executable data in general. You also may have to consider a
> few more permission complications (shared/cacheable) depending on the
> hardware.
>

The low-level mmu implementation for ARMv7 BSPS has an
'ARMV7_CP15_START_DEFAULT_SECTIONS' which lists out various regions with
appropriate permissions and then are grouped by a linker script. This
should be the standard way of handling the placement of statically
allocated regions.

>  2. The protection, size, page table, and sharing attributes of each
> created thread will be tracked.
> >
> I'd rather we not be calling this a page table. MPU-based systems
> don't have a notion of page table. But maybe it is OK as long as we
> understand that you mean the data structure responsible for mapping
> out the address space. I'm not sure what you mean by size, unless you
> refer to that thread's stack.
>
> >  3. At every context switch, these attributes will be updated, the
> static-global regions will be assigned a global ASID and will not change
> during the switch only the protected regions will be updated.
> >
> Yes, assuming the hardware supports ASIDs and a global attribute.
>
> I don't know if you will be able to pin the global entries in
> hardware. You'll want to keep an eye out for that. If not, you might
> need to do something in software to ensure they don't get evicted
> (e.g., touch them all before finishing a context switch assuming LRU
> replacement).
>
> >  4. Whenever we share stacks, the page table entries of the shared
> stack, with the access bits as specified by the mmap/shm high-level APIs
> will be installed to the current thread. This is different from simply
> providing the page table base address of the shared thread-stack ( what if
> the user wants to make the shared thread only readable from another thread
> while the 'original' thread is r/w enabled?) We will also have to update
> the TLB by installing the shared regions while the global regions remain
> untouched.
> >
>
> Correct. I think we need to make a design decision whether a stack can
> exceed one page. It will simplify things if we can assume that, but it
> may limit applications unnecessarily. Have to think on that.
>

If we go with the above assumption, we will need to increase the size of
the page i.e. pages of 16Kib or 64Kib. Most of the applications won't
require stacks of this size and will result in wasted memory for each
thread. I think it would be better if we have multiple pages, as most of
the applications will have stacks that may fit in a single 4KiB page anyway.


> The "page table base address" points to the entire structure that maps
> out a thread's address space, so you'd have to walk it to find the
> entry/entries for its stack. So, definitely not something you'd want
> to do.
>
> The shm/mmap should convey the privileges to the requesting thread
> asking to share. This will result in adding the shared entry/entries
> to that thread's address space, with the appropriately set
> permissions. So, if the entry is created with read-only permission,
> then that is how the thread will be sharing. The original thread's
> entry should not be modified by the addition of an entry in another
> thread for the same memory region.
>
> I lean toward thinking it is better to always pay for the TLB miss at
> the context switch, which might mean synthesizing accesses to the
> entries that might have been evicted in case hardware restricts the
> ability of sw to install/manipulate TLB entries directly. That is
> something worth looking at more though. There is definitely a tradeoff
> between predictable costs and throughput performance. It might be
> worth implementing both approaches.
>
> Gedare
>

We also need to consider the cases where 

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

[Gedare Bloom]

>  This means that our low-level design for providing thread stack protection 
> may look something like this:-
>
> 1. For MPU based processors, the number of protected stacks will depend on 
> the number of protection domains i.e. for MPUs with 8 protection domains we 
> can have 7 protected stacks ( 1 of the region will be assigned for global 
> data). For MMU based system we will have a section (a page of size 1MB) for 
> global data and task address space will be divided into smaller pages, page 
> sizes will be decided by keeping in mind the number of TLB entries, in a 
> manner I have described above in the thread.
>
There is value to defining a few of the global regions. I'll assume
R/W/X permissions. Then code (.text) should be R/X. read-only data
sections should be grouped together and made R. Data sections should
be RW. And then stacks should be added to the end. The linker scripts
should be used to group the related sections together. I think some
ARM BSPs do some of this already.  That seems like a minimally useful
configuration for most users that would care, they want to have also
protection of code from accidental overwrite, and probably data too,
and non-executable data in general. You also may have to consider a
few more permission complications (shared/cacheable) depending on the
hardware.

>  2. The protection, size, page table, and sharing attributes of each created 
> thread will be tracked.
>
I'd rather we not be calling this a page table. MPU-based systems
don't have a notion of page table. But maybe it is OK as long as we
understand that you mean the data structure responsible for mapping
out the address space. I'm not sure what you mean by size, unless you
refer to that thread's stack.

>  3. At every context switch, these attributes will be updated, the 
> static-global regions will be assigned a global ASID and will not change 
> during the switch only the protected regions will be updated.
>
Yes, assuming the hardware supports ASIDs and a global attribute.

I don't know if you will be able to pin the global entries in
hardware. You'll want to keep an eye out for that. If not, you might
need to do something in software to ensure they don't get evicted
(e.g., touch them all before finishing a context switch assuming LRU
replacement).

>  4. Whenever we share stacks, the page table entries of the shared stack, 
> with the access bits as specified by the mmap/shm high-level APIs will be 
> installed to the current thread. This is different from simply providing the 
> page table base address of the shared thread-stack ( what if the user wants 
> to make the shared thread only readable from another thread while the 
> 'original' thread is r/w enabled?) We will also have to update the TLB by 
> installing the shared regions while the global regions remain untouched.
>

Correct. I think we need to make a design decision whether a stack can
exceed one page. It will simplify things if we can assume that, but it
may limit applications unnecessarily. Have to think on that.

The "page table base address" points to the entire structure that maps
out a thread's address space, so you'd have to walk it to find the
entry/entries for its stack. So, definitely not something you'd want
to do.

The shm/mmap should convey the privileges to the requesting thread
asking to share. This will result in adding the shared entry/entries
to that thread's address space, with the appropriately set
permissions. So, if the entry is created with read-only permission,
then that is how the thread will be sharing. The original thread's
entry should not be modified by the addition of an entry in another
thread for the same memory region.

I lean toward thinking it is better to always pay for the TLB miss at
the context switch, which might mean synthesizing accesses to the
entries that might have been evicted in case hardware restricts the
ability of sw to install/manipulate TLB entries directly. That is
something worth looking at more though. There is definitely a tradeoff
between predictable costs and throughput performance. It might be
worth implementing both approaches.

Gedare
___
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)

[Utkarsh Rai]

On Thu, May 21, 2020 at 5:43 AM Hesham Almatary 
wrote:

> Yes, I completely agree with Gedare, and my reply doesn't entail
> otherwise. As Gedare stated a few requirements:
>
> "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."
>
> Such areas are the ones I meant to be "Global." The design and
> implementation should aim to make them stick in the TLB and don't get
> kicked out. Those aren't being assigned an ASID as they are global and
> won't need to get flushed and their mappings/attributes won't change.
>
> "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."
>
> The additional overhead here is the flushing of the protected region
> (that might be a shared protected stack for example). Only that
> region's TLB entry will differ between tasks on context switches, and
> if ASID is used, the hardware will make sure it gets the correct entry
> (by doing a HW page-table walk).
>
> On Wed, 20 May 2020 at 11:05, Utkarsh Rai  wrote:
> >
> >
> >
> >
> > On Wed, May 20, 2020 at 7:40 AM Hesham Almatary <
> heshamelmat...@gmail.com> wrote:
> >>
> >> On Tue, 19 May 2020 at 14:00, Utkarsh Rai 
> wrote:
> >> >
> >> >
> >> >
> >> > On Mon, May 18, 2020 at 8:38 PM Gedare Bloom 
> wrote:
> >> >>
> >> >> 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 <
> utkarsh.ra...@gmail.com> 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
> >> >> > > <
> 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.
> >> >> >
> >> >> > 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 t

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

[Hesham Almatary]

Yes, I completely agree with Gedare, and my reply doesn't entail
otherwise. As Gedare stated a few requirements:

"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."

Such areas are the ones I meant to be "Global." The design and
implementation should aim to make them stick in the TLB and don't get
kicked out. Those aren't being assigned an ASID as they are global and
won't need to get flushed and their mappings/attributes won't change.

"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."

The additional overhead here is the flushing of the protected region
(that might be a shared protected stack for example). Only that
region's TLB entry will differ between tasks on context switches, and
if ASID is used, the hardware will make sure it gets the correct entry
(by doing a HW page-table walk).

On Wed, 20 May 2020 at 11:05, Utkarsh Rai  wrote:
>
>
>
>
> On Wed, May 20, 2020 at 7:40 AM Hesham Almatary  
> wrote:
>>
>> On Tue, 19 May 2020 at 14:00, Utkarsh Rai  wrote:
>> >
>> >
>> >
>> > On Mon, May 18, 2020 at 8:38 PM Gedare Bloom  wrote:
>> >>
>> >> 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 'acce

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

[Utkarsh Rai]

On Wed, May 20, 2020 at 7:40 AM Hesham Almatary 
wrote:

> On Tue, 19 May 2020 at 14:00, Utkarsh Rai  wrote:
> >
> >
> >
> > On Mon, May 18, 2020 at 8:38 PM Gedare Bloom  wrote:
> >>
> >> 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 <
> 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
> >> > > <
> 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.
> >> >
> >> > 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 protecti

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

[Hesham Almatary]

On Tue, 19 May 2020 at 14:00, Utkarsh Rai  wrote:
>
>
>
> On Mon, May 18, 2020 at 8:38 PM Gedare Bloom  wrote:
>>
>> 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 

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

[Utkarsh Rai]

On Mon, May 18, 2020 at 8:38 PM Gedare Bloom  wrote:

> 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 <
> 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.
> >
>
> 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 glob

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

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)

[Joel Sherrill]

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 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.

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]

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.
>
> ___
> 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)

[Sebastian Huber]

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. 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.

___
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)

[Utkarsh Rai]

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.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Utkarsh Rai]

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.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel