Re: GSoC Project - Beagle BSP Projects

[Utkarsh Rai]

On Tue, Mar 23, 2021 at 9:36 PM Nils Hölscher  wrote:

> Hi,
>
> Regarding the PRU.
> I was able to load code to the PRU.
> However I wasn't able to map IRQ interrupts to the PRU, thus unable to
> communicate with it in a meaningful way
>


Just a small addition, AFAIK the issue with this was the fact that mmap()
would always fail.


> .
> Also I don't think that this project should be continued without a full
> DEBUGGING Setup.
>

+1, without a proper debugging setup I found it hard to precisely pin point
the problem when I initially took up this task.


>
>
Best,
> Nils
>
> On Tue, 23 Mar 2021 at 17:00, Christian MAUDERER <
> christian.maude...@embedded-brains.de> wrote:
>
>> Hello Gedare,
>>
>> Am 23.03.21 um 16:48 schrieb Gedare Bloom:
>> > CC: Nils, Utkarsh
>> >
>> > On Tue, Mar 23, 2021 at 9:17 AM Christian MAUDERER
>> >  wrote:
>> >>
>> >> Hello Ahamed,
>> >>
>> >> Am 23.03.21 um 11:24 schrieb Ahamed Husni:
>> >>> Hi everyone,
>> >>>
>> >>> I'm really interested to work on the *Beagle BSP Projects* [#2891
>> >>> ]. *
>> >>> *
>> >>> *Adding PRU Support* [#3730 ]
>> >>> project seems really interesting to me.
>> >>> This project is partially done during GSoC 2019
>> >>> by Nils Hölscher .
>> >>> Is this a good project for the GSoC?
>> >>>
>> >>> Up to now I have,
>> >>>
>> >>>   1. Completed the GSoC prerequisite task
>> >>>   2. Got the required hardware and tested it. (Beagleboard Black, USB
>> to
>> >>>  TTL Converter)
>> >>>   3. Installed RTEMS on the Beagleboard and tested. (Screenshot
>> attached
>> >>>  below)
>> >>>
>> >>>
>> >>> I need guidance to define the scope of the project.
>> >>> I'm currently thinking of ,
>> >>>
>> >>>   1. First finish the remaining work from GSoC 2019 on the PRU.
>> >>>  (What is the status of current implementation of the PRU?)
>> >>
>> >> I'm really not sure what the state of the PRU is. I didn't follow that
>> >> project closely. Maybe one of the mentors of that project can say
>> >> anything regarding that.
>> >>
>> > Some more background:
>> > https://lists.rtems.org/pipermail/devel/2019-December/056478.html
>> > https://lists.rtems.org/pipermail/devel/2020-January/056958.html
>> >
>> > Maybe Utkarsh or Nils have more to say.
>> >
>> >>>   2. Implement additional peripheral support.
>> >>>  What would be most useful?
>> >>>  (USB OTG, CAN, ...).
>> >>
>> >> I think CAN is a bit hard without some CAN analyzer hardware as a peer.
>> >>
>> >> USB OTG would be a nice area. But that will be less writing a driver
>> for
>> >> Beagle but more finding out how that works with libbsd and finding a
>> >> good way to configure it. I once put a few hours into it didn't take
>> too
>> >> much time till a PC detected an USB device (see
>> >> https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce).
>> >> Basically it's about importing the "usb_template" stuff and finding a
>> >> way to configure it in libbsd.
>> >>
>> >> I think that topic would have to be a bit of an open one: You might
>> work
>> >> only a day on it and have a working CDC Ethernet afterwards or you can
>> >> need weeks for that. So you should add an open list of possible
>> advanced
>> >> targets. An OTG device can be:
>> >>
>> >> - Ethernet
>> >> - Serial port
>> >> - Mass storage
>> >> - Keyboard / Mouse
>> >> - Modem
>> >> - Audio
>> >> - ...
>> >>
>> >> The simplest one will most likely be Ethernet followed by serial port.
>> I
>> >> would add some of the others (like mass storage) as an extended
>> targets.
>> >>
>> > Yes, this seems like an area that can be chipped away at, with a
>> > strong plan of activities. My concern would be whether it is about
>> > writing code or not?
>> >
>>
>> It won't produce a lot of code. But it will produce relevant one:
>>
>> 1. Interface for configuration (if necessary)
>>
>> 2. Example application
>>
>> 3. Documentation
>>
>> For Ethernet and serial port that's most likely it. For Mass storage
>> there might be some more code. Without a too detailed look: I would
>> expect that the mass storage either implements some access to a raw
>> block device - in which case it would be necessary to add the access to
>> block devices. Or it implements something like the PTP stuff used on
>> smartphones in which case there will be most likely some code that
>> accesses the file system using POSIX functions instead of FreeBSD kernel
>> functions.
>>
>> Best regards
>>
>> Christian
>>
>> >> Best regards
>> >>
>> >> Christian
>> >>
>> >>>
>> >>>  The builtin USB is NOT functional other than for power under
>> RTEMS.
>> >>>  (USB OTG would have to be implemented in RTEMS to get rid of USB
>> to
>> >>>  TTL Converter.)
>> >>>  - Ben Gras
>> >>>  <
>> http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html
>> >
>> >>>  (Blog post)
>> >>>
>> >>>
>> >>> Thanks,
>> >>> 

Re: GSoC project: Memory protection (Ticket no: 2904)

[Utkarsh Rai]

On Tue, Mar 23, 2021 at 5:49 PM Rajiv Vaidyanathan <
rajiv.vaidyanath...@gmail.com> wrote:

> Dear Utkarsh,
>
> Thank you for providing these links. I would like to know if these pending
> tasks are long enough to take it up as a GSoC project.
>
>
Resolving the issues related to user extension iterators and then making it
compatible with existing testsuites should be a long enough task. You can
also take up the task of thread stack sharing
if this is resolved early.



> Thanks and regards,
> Rajiv
>
> On Tue, 23 Mar 2021 at 16:15, Utkarsh Rai  wrote:
>
>>
>>
>> On Mon, Mar 22, 2021 at 9:54 PM Gedare Bloom  wrote:
>>
>>> Hi Rajiv,
>>>
>>> On Sat, Mar 20, 2021 at 12:40 AM Rajiv Vaidyanathan
>>>  wrote:
>>> >
>>> > Hello RTEMS community,
>>>
>>
>> Hello Rajiv,
>>
>>
>>> >
>>> > I am interested in the ticket: Memory protection. I saw that this
>>> topic has been pursued a few times in GSoC. It would be great if someone
>>> can let me know the current status of this project and guide me about what
>>> are the contributions that can be done this year.
>>> >
>>> Yes, this is a frequently attempted project that slowly makes progress
>>> over time. I think that Utkarsh has gotten somewhat close to a
>>> workable solution, but there were some design flaws in his approach
>>> for task stack protection (mainly, iterating over all the tasks) that
>>> are still lingering.
>>
>>
>> If you want to work on thread stack protection using MMU you can look at
>> this
>> thread
>> <https://lists.rtems.org/pipermail/devel/2020-December/063606.html> for
>> the issues with my solution and possible resolutions to them.
>> You can clone the 'Final-release' branch of this
>> <https://github.com/ur10/rtems> repo to get an idea of the
>> changes/additions that I had done and refer to this blog
>> <https://gsoc2020memoryprotection.blogspot.com/2020/05/what-is-thread-stack-protection-well.html>
>>  for
>> a brief description of my idea
>> behind making those changes/additions.
>> Ideally, I would have liked to complete them for myself, this summer, but
>> I am not sure
>> if the time constraints that I have would allow me to pursue this right
>> now.
>>
>>
>>> There could be enough work here to pick up from his progress. The
>>> major issue would be figuring out what  the final state of his code is
>>> in, and to dig in to the design and implementation details to write a
>>> concrete proposal how to bring task stack protection to a production
>>> state. There may be other directions to consider as well, such as
>>> improving the risc-v MMU support perhaps.
>>>
>>> > Thanks and regards,
>>> > Rajiv
>>> > ___
>>> > 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: GSoC project: Memory protection (Ticket no: 2904)

[Utkarsh Rai]

On Mon, Mar 22, 2021 at 9:54 PM Gedare Bloom  wrote:

> Hi Rajiv,
>
> On Sat, Mar 20, 2021 at 12:40 AM Rajiv Vaidyanathan
>  wrote:
> >
> > Hello RTEMS community,
>

Hello Rajiv,


> >
> > I am interested in the ticket: Memory protection. I saw that this topic
> has been pursued a few times in GSoC. It would be great if someone can let
> me know the current status of this project and guide me about what are the
> contributions that can be done this year.
> >
> Yes, this is a frequently attempted project that slowly makes progress
> over time. I think that Utkarsh has gotten somewhat close to a
> workable solution, but there were some design flaws in his approach
> for task stack protection (mainly, iterating over all the tasks) that
> are still lingering.


If you want to work on thread stack protection using MMU you can look at
this
thread  for
the issues with my solution and possible resolutions to them.
You can clone the 'Final-release' branch of this
 repo to get an idea of the
changes/additions that I had done and refer to this blog

for
a brief description of my idea
behind making those changes/additions.
Ideally, I would have liked to complete them for myself, this summer, but I
am not sure
if the time constraints that I have would allow me to pursue this right
now.


> There could be enough work here to pick up from his progress. The
> major issue would be figuring out what  the final state of his code is
> in, and to dig in to the design and implementation details to write a
> concrete proposal how to bring task stack protection to a production
> state. There may be other directions to consider as well, such as
> improving the risc-v MMU support perhaps.
>
> > Thanks and regards,
> > Rajiv
> > ___
> > 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: Memory Protection related project for GSOC

[Utkarsh Rai]

On Sun, Feb 21, 2021 at 12:00 AM Gedare Bloom  wrote:

> Hi Sanskar,
>
> We had a student (Utkarsh) work on this project last year. I have CC'd
> him here, and he may be able to suggest some ideas/updates.
>
> On Sat, Feb 20, 2021 at 7:17 AM Sanskar Khandelwal
>  wrote:
> >
> > Hello,
>

Hello Sanskar,


> > I want to do a project related to memory Protection, I am thinking of
> adding support for Physical Memory Protection(PMP) to risc-v based bsps.
> Actually I came across this 2 days back so I know the basic concept but I
> don't have a clear understanding of how actually it will be implemented
> yet. So before going into more detail I wanted to ask, can this be a gsoc
> project ? Also if someone can guide me on how I should proceed further it
> will be a big help.


There are a few things to be kept in mind while adding support for an
MPU/PMP. You need to get the linker script in order to place the relevant
sections (txt, bss,etc.) in the memory region of your choice. Then you need
to set up page table entries for these regions, with proper access flags,
at system startup. Setting up page table entries is an architecture
specif task, as each architecture has its own implementation of MPU/PMP(
although the overarching concept is the same). You may have to look at the
RISC-V manual and a few other sources to get a 'feel' for how this is to be
done. You can have a look at this post
,
for the low-level details of ARMv7 MMU implementation. I would suggest you
to first look at how it is done for ARMv7 MMU, by setting up a debugger and
walking through the whole process. You can take up the realview BSP for the
same.

>
> > thanks
> > --sanskar
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Report on failing tests with thread stack protection and their resolution.

[Utkarsh Rai]

On Tue, Jan 26, 2021 at 9:33 PM Gedare Bloom  wrote:

>
>
> On Tue, Jan 26, 2021 at 8:24 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 23/01/2021 07:27, Utkarsh Rai wrote:
>>
>> > The issue that remains is of User extension iterators, in particular
>> > of nested iterators. My idea is to disable memory protection in places
>> > during iteration where inter-stack access takes place.  The problem is
>> > determining the region for which memory protection needs to be
>> > disabled. One way to get around this would be by disabling memory
>> > protection for all the stacks, in a blanket-based manner.
>>
>> I used this approach for a Nios II system with a thread stack
>> protection. We trust the operating system, so this approach should be
>> fine.
>>
>> +1 that looks good for an initial solution.
> [...]
>
>
>>
>> > The other possibility is to access the last blocked thread and disable
>> > memory protection just for the stack of this thread (as inter-stack
>> > access of the previously blocked thread takes place during iteration).
>> > How to get access to the queue of blocked threads? And is this method
>> > feasible?
>> The system doesn't know the last blocked thread currently. I am not sure
>> if knowing the last blocked thread helps you here.
>>
>>
> If I recall right, there are two problems to solve.
> 1. The user extension iterator code uses thread stacks to manage some of
> its data structures. The correct fix would be to rewrite it to use some
> workspace regions probably, but this is out of scope. I suspect that this
> is the case where the last blocked thread stack is the one that gets used?
>

Yes.


>
> 2 . The user extensions themselves might touch thread stacks as they run.
> This is probably a common case that would need to be resolved like Joel
> said, by punting responsibility to the user to disable protection
> before/after touching stacks.
>
> The simple solution is to disable/enable around the call to the user
> extension iterator, while the slightly more advanced solution is to do that
> within any RTEMS-provided extensions that touch the stack. Utkarsh, you
> might want to start with the simple solution to get everything working, and
> make a plan to do the more advanced solution.
>

> It could be possible that addressing #1 and #2 is appropriate for the
> revised GSoC scope (50% as large projects).
>

Ok, I will start with the simpler solution.


>
-Gedare
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Report on failing tests with thread stack protection and their resolution.

[Utkarsh Rai]

On Sat, Jan 23, 2021 at 9:29 PM Joel Sherrill  wrote:

>
>
> On Sat, Jan 23, 2021, 12:28 AM Utkarsh Rai 
> wrote:
>
>>
>>
>> On Mon, Dec 7, 2020 at 8:00 AM Utkarsh Rai 
>> wrote:
>>
>>>
>>>
>>> On Thu, Dec 3, 2020 at 10:22 PM Gedare Bloom  wrote:
>>>
>>>>
>>>>
>>>> On Wed, Dec 2, 2020 at 5:53 PM Utkarsh Rai 
>>>> wrote:
>>>>
>>>>> Hello,
>>>>> As discussed in this
>>>>> <https://lists.rtems.org/pipermail/devel/2020-November/063341.html> 
>>>>> thread,
>>>>> I have compiled a list of the tests that deal with inter stack
>>>>> communication and fail with the thread stack protection option. Most of
>>>>> these tests pass when, as Sebastian suggested and had provided a
>>>>> wonderful example, I disable memory protection at places where contents of
>>>>> different thread stacks are accessed by the current thread. There are a 
>>>>> few
>>>>> tests that still fail due to inter-stack access in the application code
>>>>> itself.
>>>>>
>>>>> The changes I have made are -
>>>>>
>>>>> diff --git a/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
>>>>> b/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
>>>>> index c176d4b8c5..a45b175395 100644
>>>>> --- a/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
>>>>> +++ b/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
>>>>> @@ -1,15 +1,49 @@
>>>>>  #include 
>>>>>  #include 
>>>>> +#include 
>>>>>  #include 
>>>>>
>>>>> +bool set_memory_flags(Thread_Control* thread, void* arg)
>>>>> +{
>>>>> +  uintptr_t begin;
>>>>> +  uintptr_t end;
>>>>> +  uint32_t flags;
>>>>> +  rtems_interrupt_level irq_level;
>>>>> +  Thread_Control *executing;
>>>>> +
>>>>> +  executing = _Thread_Executing;
>>>>> +
>>>>> +  if(thread !=  executing) {
>>>>>
>>>> This is not concurrency-safe. By time the check happens, or following
>>>> code happens, the thread could become executing.
>>>>
>>>>
>>>>> +
>>>>> +flags = *( uint32_t *)( arg );
>>>>> +begin = thread->Start.Initial_stack.area;
>>>>> +end = begin + thread->Start.Initial_stack.size;
>>>>> +
>>>>> +rtems_interrupt_disable(irq_level);
>>>>> +arm_cp15_set_translation_table_entries(begin, end, flags);
>>>>> +rtems_interrupt_enable(irq_level);
>>>>> +  }
>>>>> +
>>>>> +  return false;
>>>>>
>>>> why -- what does the return value mean?
>>>>
>>>
>>> While iterating over threads, if the visitor returns true the iteration
>>> stops.
>>>
>>>
>>>>
>>>>
>>>>> +}
>>>>> +
>>>>> +rtems_status_code _Memory_protection_Enable( void )
>>>>> +{
>>>>> +  uint32_t access_flags;
>>>>> +
>>>>> +  access_flags = translate_flags(  RTEMS_NO_ACCESS );
>>>>> +
>>>>> +  _Thread_Iterate( set_memory_flags, _flags );
>>>>> +
>>>>> +  return RTEMS_SUCCESSFUL; // check the return values for iterating
>>>>> function and current method.
>>>>> +}
>>>>> +
>>>>> +rtems_status_code _Memory_protection_Disable( void )
>>>>> +{
>>>>> +  uint32_t access_flags;
>>>>> +
>>>>> +  access_flags = translate_flags(  RTEMS_READ_WRITE );
>>>>> +
>>>>> +  _Thread_Iterate( set_memory_flags, _flags );
>>>>> +
>>>>> +  return RTEMS_SUCCESSFUL;
>>>>>  }
>>>>> \ No newline at end of file
>>>>> diff --git a/cpukit/include/rtems/score/coremsgimpl.h
>>>>> b/cpukit/include/rtems/score/coremsgimpl.h
>>>>> index e598dce96a..3719a3d3c8 100644
>>>>> --- a/cpukit/include/rtems/score/coremsgimpl.h
>>>>> +++ b/cpukit/include/rtems/score/coremsgimpl.h
>>>>> @@ -27,6 +27,10 @@
>>>>>  #include 
>>>>>  #include 
>>>>>
>>>>> +#if defined RTEMS_THREAD_

Re: Report on failing tests with thread stack protection and their resolution.

[Utkarsh Rai]

On Mon, Dec 7, 2020 at 8:00 AM Utkarsh Rai  wrote:

>
>
> On Thu, Dec 3, 2020 at 10:22 PM Gedare Bloom  wrote:
>
>>
>>
>> On Wed, Dec 2, 2020 at 5:53 PM Utkarsh Rai 
>> wrote:
>>
>>> Hello,
>>> As discussed in this
>>> <https://lists.rtems.org/pipermail/devel/2020-November/063341.html> thread,
>>> I have compiled a list of the tests that deal with inter stack
>>> communication and fail with the thread stack protection option. Most of
>>> these tests pass when, as Sebastian suggested and had provided a
>>> wonderful example, I disable memory protection at places where contents of
>>> different thread stacks are accessed by the current thread. There are a few
>>> tests that still fail due to inter-stack access in the application code
>>> itself.
>>>
>>> The changes I have made are -
>>>
>>> diff --git a/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
>>> b/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
>>> index c176d4b8c5..a45b175395 100644
>>> --- a/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
>>> +++ b/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
>>> @@ -1,15 +1,49 @@
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>
>>> +bool set_memory_flags(Thread_Control* thread, void* arg)
>>> +{
>>> +  uintptr_t begin;
>>> +  uintptr_t end;
>>> +  uint32_t flags;
>>> +  rtems_interrupt_level irq_level;
>>> +  Thread_Control *executing;
>>> +
>>> +  executing = _Thread_Executing;
>>> +
>>> +  if(thread !=  executing) {
>>>
>> This is not concurrency-safe. By time the check happens, or following
>> code happens, the thread could become executing.
>>
>>
>>> +
>>> +flags = *( uint32_t *)( arg );
>>> +begin = thread->Start.Initial_stack.area;
>>> +end = begin + thread->Start.Initial_stack.size;
>>> +
>>> +rtems_interrupt_disable(irq_level);
>>> +arm_cp15_set_translation_table_entries(begin, end, flags);
>>> +rtems_interrupt_enable(irq_level);
>>> +  }
>>> +
>>> +  return false;
>>>
>> why -- what does the return value mean?
>>
>
> While iterating over threads, if the visitor returns true the iteration
> stops.
>
>
>>
>>
>>> +}
>>> +
>>> +rtems_status_code _Memory_protection_Enable( void )
>>> +{
>>> +  uint32_t access_flags;
>>> +
>>> +  access_flags = translate_flags(  RTEMS_NO_ACCESS );
>>> +
>>> +  _Thread_Iterate( set_memory_flags, _flags );
>>> +
>>> +  return RTEMS_SUCCESSFUL; // check the return values for iterating
>>> function and current method.
>>> +}
>>> +
>>> +rtems_status_code _Memory_protection_Disable( void )
>>> +{
>>> +  uint32_t access_flags;
>>> +
>>> +  access_flags = translate_flags(  RTEMS_READ_WRITE );
>>> +
>>> +  _Thread_Iterate( set_memory_flags, _flags );
>>> +
>>> +  return RTEMS_SUCCESSFUL;
>>>  }
>>> \ No newline at end of file
>>> diff --git a/cpukit/include/rtems/score/coremsgimpl.h
>>> b/cpukit/include/rtems/score/coremsgimpl.h
>>> index e598dce96a..3719a3d3c8 100644
>>> --- a/cpukit/include/rtems/score/coremsgimpl.h
>>> +++ b/cpukit/include/rtems/score/coremsgimpl.h
>>> @@ -27,6 +27,10 @@
>>>  #include 
>>>  #include 
>>>
>>> +#if defined RTEMS_THREAD_STACK_PROTECTION
>>> + #include 
>>> +#endif
>>> +
>>>  #include 
>>>  #include 
>>>
>>> @@ -586,7 +590,9 @@ RTEMS_INLINE_ROUTINE Thread_Control
>>> *_CORE_message_queue_Dequeue_receiver(
>>>if ( the_thread == NULL ) {
>>>  return NULL;
>>>}
>>> -
>>> +#if defined RTEMS_THREAD_STACK_PROTECTION
>>> +  _Memory_protection_Disable();
>>>
>> I wonder if it is necessary to disable all protection, or can you just
>> disable the protection applied to 'the_thread' (or maybe to 'executing')?
>>
>
> No, it is not necessary. I will make the changes.
>
>
>>
>>
>>> +#endif
>>> *(size_t *) the_thread->Wait.return_argument = size;
>>> the_thread->Wait.count = (uint32_t) submit_type;
>>>
>>> @@ -595,6 +601,9 @@ RTEMS_INLINE_ROUTINE Thread_Control
>>> *_CORE_message_queue_Dequeue_receiver(
>>>

Re: Report on failing tests with thread stack protection and their resolution.

[Utkarsh Rai]

On Thu, Dec 17, 2020 at 8:23 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> On 03/12/2020 01:53, Utkarsh Rai wrote:
> > +rtems_status_code _Memory_protection_Disable( void )
> > +{
> > +  uint32_t access_flags;
> > +
> > +  access_flags = translate_flags(  RTEMS_READ_WRITE );
> > +
> > +  _Thread_Iterate( set_memory_flags, _flags );
> > +
> > +  return RTEMS_SUCCESSFUL;
> >  }
> using _Thread_Iterate() for this is quite bad in terms of performance
> and it may also lead to unpredictable behaviour.
>

Yes,  this is wrong. Simply disabling the protection for just 'the_thread'
should be sufficient in our case.


>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Report on failing tests with thread stack protection and their resolution.

[Utkarsh Rai]

On Thu, Dec 3, 2020 at 10:22 PM Gedare Bloom  wrote:

>
>
> On Wed, Dec 2, 2020 at 5:53 PM Utkarsh Rai 
> wrote:
>
>> Hello,
>> As discussed in this
>> <https://lists.rtems.org/pipermail/devel/2020-November/063341.html> thread,
>> I have compiled a list of the tests that deal with inter stack
>> communication and fail with the thread stack protection option. Most of
>> these tests pass when, as Sebastian suggested and had provided a
>> wonderful example, I disable memory protection at places where contents of
>> different thread stacks are accessed by the current thread. There are a few
>> tests that still fail due to inter-stack access in the application code
>> itself.
>>
>> The changes I have made are -
>>
>> diff --git a/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
>> b/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
>> index c176d4b8c5..a45b175395 100644
>> --- a/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
>> +++ b/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
>> @@ -1,15 +1,49 @@
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>
>> +bool set_memory_flags(Thread_Control* thread, void* arg)
>> +{
>> +  uintptr_t begin;
>> +  uintptr_t end;
>> +  uint32_t flags;
>> +  rtems_interrupt_level irq_level;
>> +  Thread_Control *executing;
>> +
>> +  executing = _Thread_Executing;
>> +
>> +  if(thread !=  executing) {
>>
> This is not concurrency-safe. By time the check happens, or following code
> happens, the thread could become executing.
>
>
>> +
>> +flags = *( uint32_t *)( arg );
>> +begin = thread->Start.Initial_stack.area;
>> +end = begin + thread->Start.Initial_stack.size;
>> +
>> +rtems_interrupt_disable(irq_level);
>> +arm_cp15_set_translation_table_entries(begin, end, flags);
>> +rtems_interrupt_enable(irq_level);
>> +  }
>> +
>> +  return false;
>>
> why -- what does the return value mean?
>

While iterating over threads, if the visitor returns true the iteration
stops.


>
>
>> +}
>> +
>> +rtems_status_code _Memory_protection_Enable( void )
>> +{
>> +  uint32_t access_flags;
>> +
>> +  access_flags = translate_flags(  RTEMS_NO_ACCESS );
>> +
>> +  _Thread_Iterate( set_memory_flags, _flags );
>> +
>> +  return RTEMS_SUCCESSFUL; // check the return values for iterating
>> function and current method.
>> +}
>> +
>> +rtems_status_code _Memory_protection_Disable( void )
>> +{
>> +  uint32_t access_flags;
>> +
>> +  access_flags = translate_flags(  RTEMS_READ_WRITE );
>> +
>> +  _Thread_Iterate( set_memory_flags, _flags );
>> +
>> +  return RTEMS_SUCCESSFUL;
>>  }
>> \ No newline at end of file
>> diff --git a/cpukit/include/rtems/score/coremsgimpl.h
>> b/cpukit/include/rtems/score/coremsgimpl.h
>> index e598dce96a..3719a3d3c8 100644
>> --- a/cpukit/include/rtems/score/coremsgimpl.h
>> +++ b/cpukit/include/rtems/score/coremsgimpl.h
>> @@ -27,6 +27,10 @@
>>  #include 
>>  #include 
>>
>> +#if defined RTEMS_THREAD_STACK_PROTECTION
>> + #include 
>> +#endif
>> +
>>  #include 
>>  #include 
>>
>> @@ -586,7 +590,9 @@ RTEMS_INLINE_ROUTINE Thread_Control
>> *_CORE_message_queue_Dequeue_receiver(
>>if ( the_thread == NULL ) {
>>  return NULL;
>>}
>> -
>> +#if defined RTEMS_THREAD_STACK_PROTECTION
>> +  _Memory_protection_Disable();
>>
> I wonder if it is necessary to disable all protection, or can you just
> disable the protection applied to 'the_thread' (or maybe to 'executing')?
>

No, it is not necessary. I will make the changes.


>
>
>> +#endif
>> *(size_t *) the_thread->Wait.return_argument = size;
>> the_thread->Wait.count = (uint32_t) submit_type;
>>
>> @@ -595,6 +601,9 @@ RTEMS_INLINE_ROUTINE Thread_Control
>> *_CORE_message_queue_Dequeue_receiver(
>>  the_thread->Wait.return_argument_second.mutable_object,
>>  size
>>);
>> +#if defined RTEMS_THREAD_STACK_PROTECTION
>> +  _Memory_protection_Enable();
>> +#endif
>>
>>_Thread_queue_Extract_critical(
>>  _message_queue->Wait_queue.Queue,
>>
>> diff --git a/cpukit/posix/src/psignalunblockthread.c
>> b/cpukit/posix/src/psignalunblockthread.c
>> index 80a0f33a09..e0f8468de6 100644
>> --- a/cpukit/posix/src/psignalunblockthread.c
>> +++ b/cpukit/posix/src/psignalunblockthread.

Report on failing tests with thread stack protection and their resolution.

[Utkarsh Rai]

Hello,
As discussed in this
 thread,
I have compiled a list of the tests that deal with inter stack
communication and fail with the thread stack protection option. Most of
these tests pass when, as Sebastian suggested and had provided a
wonderful example, I disable memory protection at places where contents of
different thread stacks are accessed by the current thread. There are a few
tests that still fail due to inter-stack access in the application code
itself.

The changes I have made are -

diff --git a/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
b/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
index c176d4b8c5..a45b175395 100644
--- a/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
+++ b/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
@@ -1,15 +1,49 @@
 #include 
 #include 
+#include 
 #include 

+bool set_memory_flags(Thread_Control* thread, void* arg)
+{
+  uintptr_t begin;
+  uintptr_t end;
+  uint32_t flags;
+  rtems_interrupt_level irq_level;
+  Thread_Control *executing;
+
+  executing = _Thread_Executing;
+
+  if(thread !=  executing) {
+
+flags = *( uint32_t *)( arg );
+begin = thread->Start.Initial_stack.area;
+end = begin + thread->Start.Initial_stack.size;
+
+rtems_interrupt_disable(irq_level);
+arm_cp15_set_translation_table_entries(begin, end, flags);
+rtems_interrupt_enable(irq_level);
+  }
+
+  return false;
+}
+
+rtems_status_code _Memory_protection_Enable( void )
+{
+  uint32_t access_flags;
+
+  access_flags = translate_flags(  RTEMS_NO_ACCESS );
+
+  _Thread_Iterate( set_memory_flags, _flags );
+
+  return RTEMS_SUCCESSFUL; // check the return values for iterating
function and current method.
+}
+
+rtems_status_code _Memory_protection_Disable( void )
+{
+  uint32_t access_flags;
+
+  access_flags = translate_flags(  RTEMS_READ_WRITE );
+
+  _Thread_Iterate( set_memory_flags, _flags );
+
+  return RTEMS_SUCCESSFUL;
 }
\ No newline at end of file
diff --git a/cpukit/include/rtems/score/coremsgimpl.h
b/cpukit/include/rtems/score/coremsgimpl.h
index e598dce96a..3719a3d3c8 100644
--- a/cpukit/include/rtems/score/coremsgimpl.h
+++ b/cpukit/include/rtems/score/coremsgimpl.h
@@ -27,6 +27,10 @@
 #include 
 #include 

+#if defined RTEMS_THREAD_STACK_PROTECTION
+ #include 
+#endif
+
 #include 
 #include 

@@ -586,7 +590,9 @@ RTEMS_INLINE_ROUTINE Thread_Control
*_CORE_message_queue_Dequeue_receiver(
   if ( the_thread == NULL ) {
 return NULL;
   }
-
+#if defined RTEMS_THREAD_STACK_PROTECTION
+  _Memory_protection_Disable();
+#endif
*(size_t *) the_thread->Wait.return_argument = size;
the_thread->Wait.count = (uint32_t) submit_type;

@@ -595,6 +601,9 @@ RTEMS_INLINE_ROUTINE Thread_Control
*_CORE_message_queue_Dequeue_receiver(
 the_thread->Wait.return_argument_second.mutable_object,
 size
   );
+#if defined RTEMS_THREAD_STACK_PROTECTION
+  _Memory_protection_Enable();
+#endif

   _Thread_queue_Extract_critical(
 _message_queue->Wait_queue.Queue,

diff --git a/cpukit/posix/src/psignalunblockthread.c
b/cpukit/posix/src/psignalunblockthread.c
index 80a0f33a09..e0f8468de6 100644
--- a/cpukit/posix/src/psignalunblockthread.c
+++ b/cpukit/posix/src/psignalunblockthread.c
@@ -24,6 +24,9 @@
 #include 

 #include 
+#if defined RTEMS_THREAD_STACK_PROTECTION
+#include 
+#endif
 #include 
 #include 
 #include 
@@ -205,6 +208,10 @@ bool _POSIX_signals_Unblock_thread(

   the_info = (siginfo_t *) the_thread->Wait.return_argument;

+#if defined RTEMS_THREAD_STACK_PROTECTION
+_Memory_protection_Disable();
+#endif
+
   if ( !info ) {
 the_info->si_signo = signo;
 the_info->si_code = SI_USER;
@@ -212,6 +219,9 @@ bool _POSIX_signals_Unblock_thread(
   } else {
 *the_info = *info;
   }
+#if defined RTEMS_THREAD_STACK_PROTECTION
+_Memory_protection_Enable();
+#endif

   _Thread_queue_Extract_with_proxy( the_thread );
   return _POSIX_signals_Unblock_thread_done( the_thread, api, true );
diff --git a/cpukit/rtems/src/eventsurrender.c
b/cpukit/rtems/src/eventsurrender.c
index 49f77d2663..5de62ec292 100644
--- a/cpukit/rtems/src/eventsurrender.c
+++ b/cpukit/rtems/src/eventsurrender.c
@@ -23,6 +23,10 @@
 #include 
 #include 

+#if defined RTEMS_THREAD_STACK_PROTECTION
+  #include 
+#endif
+
 static void _Event_Satisfy(
   Thread_Control  *the_thread,
   Event_Control   *event,
@@ -31,7 +35,13 @@ static void _Event_Satisfy(
 )
 {
   event->pending_events = _Event_sets_Clear( pending_events, seized_events
);
+#if defined RTEMS_THREAD_STACK_PROTECTION
+_Memory_protection_Disable();
+#endif
   *(rtems_event_set *) the_thread->Wait.return_argument = seized_events;
+#if defined RTEMS_THREAD_STACK_PROTECTION
+_Memory_protection_Enable();
+#endif
 }

 static bool _Event_Is_blocking_on_event(
diff --git a/cpukit/rtems/src/regionprocessqueue.c
b/cpukit/rtems/src/regionprocessqueue.c
index 4adaf66674..29b078a38c 100644
--- 

Re: [PATCH v4 0/1] Test for clock_nanosleep() with CLOCK_MONOTONIC option

[Utkarsh Rai]

Hello,
Is there any update on this patch?

On Wed, Oct 28, 2020 at 7:04 PM Utkarsh Rai  wrote:

> Ping.
>
> On Wed, Oct 21, 2020 at 8:58 AM Utkarsh Rai 
> wrote:
>
>> This patch has the tests for clock_nanosleep with the CLOCK_MONOTONIC
>> option.
>> The psxtests/psxclocknanosleep01/.. tests for valid timeout values as
>> well as
>> for the effect on timeout delay when REALTIME clock is modified(no
>> effect).
>> The timing tests are the similar to that for the REALTIME option(yielding
>> and
>> blocking).
>>
>> Utkarsh Rai (1):
>>   Test for clock_nanosleep() with CLOCK_MONOTONIC option
>>
>>  .../psxtests/psxclocknanosleep01.yml  |  19 +++
>>  spec/build/testsuites/psxtmtests/grp.yml  |   4 +
>>  .../psxtmtests/psxtmclocknanosleep04.yml  |  19 +++
>>  .../psxtmtests/psxtmclocknanosleep05.yml  |  19 +++
>>  .../psxtests/psxclocknanosleep01/init.c   | 145 ++
>>  .../psxclocknanosleep01.doc   |  13 ++
>>  .../psxclocknanosleep01.scn   |  50 ++
>>  .../psxtmtests/psxtmclocknanosleep04/init.c   |  70 +
>>  .../psxtmtests/psxtmclocknanosleep05/init.c   | 116 ++
>>  9 files changed, 455 insertions(+)
>>  create mode 100644 spec/build/testsuites/psxtests/psxclocknanosleep01.yml
>>  create mode 100644
>> spec/build/testsuites/psxtmtests/psxtmclocknanosleep04.yml
>>  create mode 100644
>> spec/build/testsuites/psxtmtests/psxtmclocknanosleep05.yml
>>  create mode 100644 testsuites/psxtests/psxclocknanosleep01/init.c
>>  create mode 100644
>> testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.doc
>>  create mode 100644
>> testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.scn
>>  create mode 100644 testsuites/psxtmtests/psxtmclocknanosleep04/init.c
>>  create mode 100644 testsuites/psxtmtests/psxtmclocknanosleep05/init.c
>>
>> --
>> 2.25.1
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Fatal exceptions on context-switching for more than two isolated threads

[Utkarsh Rai]

On Thu, Nov 19, 2020 at 11:39 PM Gedare Bloom  wrote:

> Hi Utkarsh,
>
> On Thu, Nov 19, 2020 at 4:59 AM Sebastian Huber
>  wrote:
> >
> > On 19/11/2020 11:47, Utkarsh Rai wrote:
> >
> > > There are a couple of other areas in RTEMS in which the stack of
> > > another
> > > thread may be accessed (events, message queues, signals). How did
> you
> > > solve this?
> > >
> > >
> > > When we enable the thread stack protection, all the services in which
> > > a different stack is accessed becomes invalid ( This will have to be
> > > documented  ).
> > > The user has to share the stack of the threads that will be using
> > > services like message queue with each other from the application using
> > > mmap(),shm_open(), etc. (This was a part of the work I did during
> GSoC).
> >
> > This is a bit too restrictive from my point of view. Consider for
> > example this very common use of rtems_event_receive():
> >
> > rtems_event_set events;
> >
> > rtems_event_receive(..., , ...);
> >
> Let's try to keep the technical discussion on the mailing list.


Oh sorry, I somehow forgot to cc the mailing list.


> I
> agree with Sebastian's point here, which is well taken. Maybe it would
> be good for you to determine the set of tests and from that the
> features that break with strict task isolation. This way, we can
> determine whether each is better handled as imposing a requirement on
> the user, e.g., to mmap/share explicitly in case they want to pass
> data (such as with an mq), or if RTEMS needs to make it work
> implicitly such as with event sets and maybe these iterators.
>
> Gedare
>


Ok.


>
> > --
> > embedded brains GmbH
> > Sebastian HUBER
> > Dornierstr. 4
> > 82178 Puchheim
> > Germany
> > email: sebastian.hu...@embedded-brains.de
> > Phone: +49-89-18 94 741 - 16
> > Fax:   +49-89-18 94 741 - 08
> > PGP: Public key available on request.
> >
> > embedded brains GmbH
> > Registergericht: Amtsgericht München
> > Registernummer: HRB 157899
> > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> > Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Fatal exceptions on context-switching for more than two isolated threads

[Utkarsh Rai]

On Thu, Nov 5, 2020 at 11:45 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 04/11/2020 19:38, Gedare Bloom wrote:
>
> >>   Based on the above suggestions I tried to move the
> User_extensions_Iterator storage to the TCB by adding a new field to the
> structure, but that did not compile(userextimpl.h is not included with
> thread.h because of cyclic dependency).
> >> This made me try out a naive hack, I defined a structure similar to the
> User_extensions_Iterator and then added the field to the TCB. The next
> problem that I faced was during the creation of the idle thread. Since an
> idle thread is created during system
> >> initialization, the 'executing' pointer pointing the TCB is null, and
> hence referencing to the iterator placed in the TCB for the idle thread
> fails. This was resolved by separating the cases for an idle thread and
> other threads. After that I was able to successfully isolate more than two
> thread stacks.
> >> Can you please suggest a more acceptable approach for resolving this
> issue?
> >>
> > At a high level the approach you took makes sense. You have moved the
> > user extensions to the TCB, and then avoid accessing it in case the
> > TCB is null (i.e., the initial context switch). I'd need to see the
> > code to make any further critical analysis. But it sounds acceptable
> > to me.
> The executing thread pointer can be NULL and there is already a check
> for this in _User_extensions_Iterate(). In this case you can use a
> member in the _Per_CPU_Information[].
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
Based on your comments I have made the following changes in the user
extension iterator scheme. Some of the code is still hackish( if-else
conditional for handling TCB pointer when it is NULL ) and I would request
your suggestions on the same.

diff --git a/cpukit/include/rtems/score/percpu.h
b/cpukit/include/rtems/score/percpu.h
index 31bc2b0bff..6e15f4b1ba 100644
--- a/cpukit/include/rtems/score/percpu.h
+++ b/cpukit/include/rtems/score/percpu.h
@@ -25,7 +25,7 @@
   #include 
 #else
   #include 
-  #include 
+  #include 
   #include 
   #include 
   #include 
@@ -339,6 +339,20 @@ typedef enum {
   PER_CPU_WATCHDOG_COUNT
 } Per_CPU_Watchdog_index;

+#if defined ( RTEMS_THREAD_STACK_PROTECTION )
+  /**
+   * @brief  Per CPU user extensions iterator structure
+   *
+   * This structure is used to refer to the user extensions iterator when
+   * thread stack protection is configured.
+  */
+typedef struct Per_CPU_User_extensions_Iterator {
+  Chain_Iterator   Iterator;
+  struct Per_CPU_User_extensions_Iterator *previous;
+} Per_CPU_User_extensions_Iterator;
+#endif
+
+
 /**
  *  @brief Per CPU Core Structure
  *
@@ -595,6 +609,10 @@ typedef struct Per_CPU_Control {
 bool boot;
   #endif

+  #if defined (RTEMS_THREAD_STACK_PROTECTION)
+Per_CPU_User_extensions_Iterator iter;
+  #endif
+
   struct Record_Control *record;

   Per_CPU_Stats Stats;
diff --git a/cpukit/include/rtems/score/thread.h
b/cpukit/include/rtems/score/thread.h
index ee0aee5b79..98b85a66af 100644
--- a/cpukit/include/rtems/score/thread.h
+++ b/cpukit/include/rtems/score/thread.h
@@ -636,6 +636,13 @@ struct Thread_Action {
   Thread_Action_handler handler;
 };

+#if defined (RTEMS_THREAD_STACK_PROTECTION)
+  typedef struct Thread_User_extensions_Iterator {
+Chain_Iterator   Iterator;
+struct Thread_User_extensions_Iterator *previous;
+  } Thread_User_extensions_Iterator;
+#endif
+
 /**
  * @brief Per-thread information for POSIX Keys.
  */
@@ -864,6 +871,10 @@ struct _Thread_Control {
*/
   struct _pthread_cleanup_context *last_cleanup_context;

+#if defined (RTEMS_THREAD_STACK_PROTECTION)
+  Thread_User_extensions_Iterator iter;
+#endif
+
   /**
* @brief LIFO list of user extensions iterators.
*/
diff --git a/cpukit/score/src/userextiterate.c
b/cpukit/score/src/userextiterate.c
index 06665a2d7a..814e695018 100644
--- a/cpukit/score/src/userextiterate.c
+++ b/cpukit/score/src/userextiterate.c
@@ -181,22 +181,47 @@ void _User_extensions_Iterate(

   _User_extensions_Acquire( _context );

-  _Chain_Iterator_initialize(
+  if ( executing != NULL ) {
+executing->iter.previous = executing->last_user_extensions_iterator;
+executing->last_user_extensions_iterator = >iter;
+
+ _Chain_Iterator_initialize(
 &_User_extensions_List.Active,
 &_User_extensions_List.Iterators,
-,
+>iter.Iterator,
 direction
   );

-  if ( executing != NULL ) {
-iter.previous = executing->last_user_extensions_iterator;
-executing->last_user_extensions_iterator = 
+while ( ( node = _Chain_Iterator_next( >iter.Iterator ) )
!= end ) {

Re: [PATCH v4 0/1] Test for clock_nanosleep() with CLOCK_MONOTONIC option

[Utkarsh Rai]

On Thu, Nov 5, 2020 at 12:13 AM Gedare Bloom  wrote:

> i need to find time to look at this, and try it out.
>
> Does this compile? e.g., I don't see a definition of OPERATION_COUNT
>

Yes,  the OPERATION_COUNT is defined in "timesys.h".

>
> On Wed, Oct 28, 2020 at 7:34 AM Utkarsh Rai 
> wrote:
> >
> > Ping.
> >
> > On Wed, Oct 21, 2020 at 8:58 AM Utkarsh Rai 
> wrote:
> >>
> >> This patch has the tests for clock_nanosleep with the CLOCK_MONOTONIC
> option.
> >> The psxtests/psxclocknanosleep01/.. tests for valid timeout values as
> well as
> >> for the effect on timeout delay when REALTIME clock is modified(no
> effect).
> >> The timing tests are the similar to that for the REALTIME
> option(yielding and
> >> blocking).
> >>
> >> Utkarsh Rai (1):
> >>   Test for clock_nanosleep() with CLOCK_MONOTONIC option
> >>
> >>  .../psxtests/psxclocknanosleep01.yml  |  19 +++
> >>  spec/build/testsuites/psxtmtests/grp.yml  |   4 +
> >>  .../psxtmtests/psxtmclocknanosleep04.yml  |  19 +++
> >>  .../psxtmtests/psxtmclocknanosleep05.yml  |  19 +++
> >>  .../psxtests/psxclocknanosleep01/init.c   | 145 ++
> >>  .../psxclocknanosleep01.doc   |  13 ++
> >>  .../psxclocknanosleep01.scn   |  50 ++
> >>  .../psxtmtests/psxtmclocknanosleep04/init.c   |  70 +
> >>  .../psxtmtests/psxtmclocknanosleep05/init.c   | 116 ++
> >>  9 files changed, 455 insertions(+)
> >>  create mode 100644
> spec/build/testsuites/psxtests/psxclocknanosleep01.yml
> >>  create mode 100644
> spec/build/testsuites/psxtmtests/psxtmclocknanosleep04.yml
> >>  create mode 100644
> spec/build/testsuites/psxtmtests/psxtmclocknanosleep05.yml
> >>  create mode 100644 testsuites/psxtests/psxclocknanosleep01/init.c
> >>  create mode 100644
> testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.doc
> >>  create mode 100644
> testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.scn
> >>  create mode 100644 testsuites/psxtmtests/psxtmclocknanosleep04/init.c
> >>  create mode 100644 testsuites/psxtmtests/psxtmclocknanosleep05/init.c
> >>
> >> --
> >> 2.25.1
> >>
> > ___
> > 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: Fatal exceptions on context-switching for more than two isolated threads

[Utkarsh Rai]

On Fri, Oct 23, 2020 at 10:28 PM Utkarsh Rai 
wrote:

>
>
> On Fri, Oct 23, 2020 at 9:57 PM Gedare Bloom  wrote:
>
>> On Fri, Oct 23, 2020 at 9:37 AM Utkarsh Rai 
>> wrote:
>> >
>> >
>> >
>> > On Thu, Oct 22, 2020 at 11:23 PM Sebastian Huber <
>> sebastian.hu...@embedded-brains.de> wrote:
>> >>
>> >> On 22/10/2020 02:40, Utkarsh Rai wrote:
>> >>
>> >> > Hello, this thread has gone a bit cold over the last few weeks, due
>> to
>> >> > my engagement in the university tests.  I have provided a debug trace
>> >> > for the issue.  The reason for fatal exceptions is the fact that
>> while
>> >> > iterating over the chain of user extensions we access a node whose
>> >> > memory location has been set to NO-ACCESS during the context switch.
>> >> > Is there any work-around to this?
>> >>
>> >> The option is to move the User_extensions_Iterator storage out of the
>> >> stack to Thread_Control and Per_CPU_Control.
>> >>
>> >
>> > Does this mean that I should add User_extensions_Iterator field in the
>> Thread_Control structure for the case
>> > when we enable thread stack protection?
>> >
>>
>> You need to dig in a little bit more. From what I understand, there is
>> the last_user_extensions_iterator field of the TCB. That is probably
>> where you are running into some trouble. See
>> score/src/userextiterate.c :193 where this field gets assigned to a
>> stack-local variable.
>
>
> I get an exception just before this when _Chain_Iterator_initialize() is
> called, the reason though is the same, accessing
> a stack-local variable of a switched out thread. From what I could
> understand,  the 'iter' variable(corresponding to the
> User_extensions_Iterator type)
> is the only stack-local variable of a switched out thread that is accessed
> from a different thread.
>
>
>> Then, you can't walk this chain when the thread
>> is out of context.
>>
>> >>
>> >> --
>> >> Sebastian Huber, embedded brains GmbH
>> >>
>> >> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> >> Phone   : +49 89 189 47 41-16
>> >> Fax : +49 89 189 47 41-09
>> >> E-Mail  : sebastian.hu...@embedded-brains.de
>> >> PGP : Public key available on request.
>> >>
>> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>> >>
>>
>

 Based on the above suggestions I tried to move the
User_extensions_Iterator storage to the TCB by adding a new field to the
structure, but that did not compile(userextimpl.h is not included with
thread.h because of cyclic dependency).
This made me try out a naive hack, I defined a structure similar to the
User_extensions_Iterator and then added the field to the TCB. The next
problem that I faced was during the creation of the idle thread. Since an
idle thread is created during system
initialization, the 'executing' pointer pointing the TCB is null, and hence
referencing to the iterator placed in the TCB for the idle thread fails.
This was resolved by separating the cases for an idle thread and other
threads. After that I was able to successfully isolate more than two thread
stacks.
Can you please suggest a more acceptable approach for resolving this issue?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v4 0/1] Test for clock_nanosleep() with CLOCK_MONOTONIC option

[Utkarsh Rai]

Ping.

On Wed, Oct 21, 2020 at 8:58 AM Utkarsh Rai  wrote:

> This patch has the tests for clock_nanosleep with the CLOCK_MONOTONIC
> option.
> The psxtests/psxclocknanosleep01/.. tests for valid timeout values as well
> as
> for the effect on timeout delay when REALTIME clock is modified(no effect).
> The timing tests are the similar to that for the REALTIME option(yielding
> and
> blocking).
>
> Utkarsh Rai (1):
>   Test for clock_nanosleep() with CLOCK_MONOTONIC option
>
>  .../psxtests/psxclocknanosleep01.yml  |  19 +++
>  spec/build/testsuites/psxtmtests/grp.yml  |   4 +
>  .../psxtmtests/psxtmclocknanosleep04.yml  |  19 +++
>  .../psxtmtests/psxtmclocknanosleep05.yml  |  19 +++
>  .../psxtests/psxclocknanosleep01/init.c   | 145 ++
>  .../psxclocknanosleep01.doc   |  13 ++
>  .../psxclocknanosleep01.scn   |  50 ++
>  .../psxtmtests/psxtmclocknanosleep04/init.c   |  70 +
>  .../psxtmtests/psxtmclocknanosleep05/init.c   | 116 ++
>  9 files changed, 455 insertions(+)
>  create mode 100644 spec/build/testsuites/psxtests/psxclocknanosleep01.yml
>  create mode 100644
> spec/build/testsuites/psxtmtests/psxtmclocknanosleep04.yml
>  create mode 100644
> spec/build/testsuites/psxtmtests/psxtmclocknanosleep05.yml
>  create mode 100644 testsuites/psxtests/psxclocknanosleep01/init.c
>  create mode 100644
> testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.doc
>  create mode 100644
> testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.scn
>  create mode 100644 testsuites/psxtmtests/psxtmclocknanosleep04/init.c
>  create mode 100644 testsuites/psxtmtests/psxtmclocknanosleep05/init.c
>
> --
> 2.25.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Fatal exceptions on context-switching for more than two isolated threads

[Utkarsh Rai]

On Fri, Oct 23, 2020 at 9:57 PM Gedare Bloom  wrote:

> On Fri, Oct 23, 2020 at 9:37 AM Utkarsh Rai 
> wrote:
> >
> >
> >
> > On Thu, Oct 22, 2020 at 11:23 PM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> >>
> >> On 22/10/2020 02:40, Utkarsh Rai wrote:
> >>
> >> > Hello, this thread has gone a bit cold over the last few weeks, due to
> >> > my engagement in the university tests.  I have provided a debug trace
> >> > for the issue.  The reason for fatal exceptions is the fact that while
> >> > iterating over the chain of user extensions we access a node whose
> >> > memory location has been set to NO-ACCESS during the context switch.
> >> > Is there any work-around to this?
> >>
> >> The option is to move the User_extensions_Iterator storage out of the
> >> stack to Thread_Control and Per_CPU_Control.
> >>
> >
> > Does this mean that I should add User_extensions_Iterator field in the
> Thread_Control structure for the case
> > when we enable thread stack protection?
> >
>
> You need to dig in a little bit more. From what I understand, there is
> the last_user_extensions_iterator field of the TCB. That is probably
> where you are running into some trouble. See
> score/src/userextiterate.c :193 where this field gets assigned to a
> stack-local variable.


I get an exception just before this when _Chain_Iterator_initialize() is
called, the reason though is the same, accessing
a stack-local variable of a switched out thread. From what I could
understand,  the 'iter' variable(corresponding to the
User_extensions_Iterator type)
is the only stack-local variable of a switched out thread that is accessed
from a different thread.


> Then, you can't walk this chain when the thread
> is out of context.
>
> >>
> >> --
> >> Sebastian Huber, embedded brains GmbH
> >>
> >> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> >> Phone   : +49 89 189 47 41-16
> >> Fax : +49 89 189 47 41-09
> >> E-Mail  : sebastian.hu...@embedded-brains.de
> >> PGP : Public key available on request.
> >>
> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> >>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Fatal exceptions on context-switching for more than two isolated threads

[Utkarsh Rai]

On Thu, Oct 22, 2020 at 11:23 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 22/10/2020 02:40, Utkarsh Rai wrote:
>
> > Hello, this thread has gone a bit cold over the last few weeks, due to
> > my engagement in the university tests.  I have provided a debug trace
> > for the issue.  The reason for fatal exceptions is the fact that while
> > iterating over the chain of user extensions we access a node whose
> > memory location has been set to NO-ACCESS during the context switch.
> > Is there any work-around to this?
>
> The option is to move the User_extensions_Iterator storage out of the
> stack to Thread_Control and Per_CPU_Control.
>
>
Does this mean that I should add User_extensions_Iterator field in the
Thread_Control structure for the case
when we enable thread stack protection?


> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Fatal exceptions on context-switching for more than two isolated threads

[Utkarsh Rai]

Hello, this thread has gone a bit cold over the last few weeks, due to my
engagement in the university tests.  I have provided a debug trace for the
issue.  The reason for fatal exceptions is the fact that while iterating
over the chain of user extensions we access a node whose memory location
has been set to NO-ACCESS during the context switch. Is there any
work-around to this?


On Tue, Sep 22, 2020 at 8:28 PM Utkarsh Rai  wrote:

>
>
>
> On Mon, Sep 21, 2020 at 10:29 PM Gedare Bloom  wrote:
>
>> On Sat, Sep 19, 2020 at 5:41 AM Utkarsh Rai 
>> wrote:
>> >
>> > Hello,
>> > When I isolate more than two threads in RTEMS (the implementation can
>> be found here), I get fatal exceptions while context-switching. On stepping
>> into the code, the problem seems to be with the _User_extensions_Thread_*()
>> call  just after a context-switch, in particular when the iterators are
>> initialized inside this call. The issue is the fact that we mark the stack
>> space of the switched out thread as 'NO_ACESS' and then try to access
>> iterators(which belong to the stack space of the switched-out thread) from
>> a different thread, which leads to fatal exceptions.
>> > I am not sure how to handle this issue because I am not very clear on
>> the purpose of the "user extension" functionality or its implementation.
>> Any help would be appreciated, as this may possibly be the last hurdle for
>> a mergeable thread stack isolation feature.
>>
>> Are you testing in an SMP configuration? The user extensions in
>> uniprocessor run before the context switch.
>
>
> No, I am running with a simple uniprocessor configuration.
>
>
>> It would help if you
>> provide a trace of your debug.
>
>
> The backtrace -
>
> _Chain_Append_unprotected (the_chain=0x2002a0 <_User_extensions_List+12>,
> the_node=0xfbf4fa0) at
> ../../../cpukit/include/rtems/score/chainimpl.h:694
> #1  0x0010d630 in _Chain_Iterator_initialize (
> the_chain=0x200294 <_User_extensions_List>,
> the_registry=0x2002a0 <_User_extensions_List+12>,
> the_iterator=0xfbf4fa0,
> direction=CHAIN_ITERATOR_FORWARD)
> at ../../../cpukit/include/rtems/score/chainimpl.h:1065
> #2  0x0010d92e in _User_extensions_Iterate (
> arg=0x201df8 <_POSIX_Threads_Objects+2016>,
> visitor=0x10d7f5 <_User_extensions_Thread_begin_visitor>,
> direction=CHAIN_ITERATOR_FORWARD)
> at ../../../cpukit/score/src/userextiterate.c:184
> #3  0x0010a172 in _User_extensions_Thread_begin (
> executing=0x201df8 <_POSIX_Threads_Objects+2016>)
> at ../../../cpukit/include/rtems/score/userextimpl.h:353
> #4  0x0010a21c in _Thread_Handler ()
> at ../../../cpukit/score/src/threadhandler.c:140
> #5  0x0010e1e8 in _CPU_Context_switch_arm ()
> at ../../../cpukit/score/cpu/arm/cpu_asm.S:121
>
>

The previous node of the chain was at 0xfbf7a0 which has been set to
NO-ACCESS during the context switch.


> You might consider using the event
>> recorder to also help with your debugging.
>> https://docs.rtems.org/branches/master/user/tracing/index.html
>
>
> Ok,  I will look into it.
>
>
>>
>>
>>
>> > ___
>> > 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

[PATCH v4 0/1] Test for clock_nanosleep() with CLOCK_MONOTONIC option

[Utkarsh Rai]

This patch has the tests for clock_nanosleep with the CLOCK_MONOTONIC option.
The psxtests/psxclocknanosleep01/.. tests for valid timeout values as well as
for the effect on timeout delay when REALTIME clock is modified(no effect).
The timing tests are the similar to that for the REALTIME option(yielding and 
blocking).

Utkarsh Rai (1):
  Test for clock_nanosleep() with CLOCK_MONOTONIC option

 .../psxtests/psxclocknanosleep01.yml  |  19 +++
 spec/build/testsuites/psxtmtests/grp.yml  |   4 +
 .../psxtmtests/psxtmclocknanosleep04.yml  |  19 +++
 .../psxtmtests/psxtmclocknanosleep05.yml  |  19 +++
 .../psxtests/psxclocknanosleep01/init.c   | 145 ++
 .../psxclocknanosleep01.doc   |  13 ++
 .../psxclocknanosleep01.scn   |  50 ++
 .../psxtmtests/psxtmclocknanosleep04/init.c   |  70 +
 .../psxtmtests/psxtmclocknanosleep05/init.c   | 116 ++
 9 files changed, 455 insertions(+)
 create mode 100644 spec/build/testsuites/psxtests/psxclocknanosleep01.yml
 create mode 100644 spec/build/testsuites/psxtmtests/psxtmclocknanosleep04.yml
 create mode 100644 spec/build/testsuites/psxtmtests/psxtmclocknanosleep05.yml
 create mode 100644 testsuites/psxtests/psxclocknanosleep01/init.c
 create mode 100644 
testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.doc
 create mode 100644 
testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.scn
 create mode 100644 testsuites/psxtmtests/psxtmclocknanosleep04/init.c
 create mode 100644 testsuites/psxtmtests/psxtmclocknanosleep05/init.c

-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v4 1/1] Test for clock_nanosleep() with CLOCK_MONOTONIC option

[Utkarsh Rai]

---
 .../psxtests/psxclocknanosleep01.yml  |  19 +++
 spec/build/testsuites/psxtmtests/grp.yml  |   4 +
 .../psxtmtests/psxtmclocknanosleep04.yml  |  19 +++
 .../psxtmtests/psxtmclocknanosleep05.yml  |  19 +++
 .../psxtests/psxclocknanosleep01/init.c   | 145 ++
 .../psxclocknanosleep01.doc   |  13 ++
 .../psxclocknanosleep01.scn   |  50 ++
 .../psxtmtests/psxtmclocknanosleep04/init.c   |  70 +
 .../psxtmtests/psxtmclocknanosleep05/init.c   | 116 ++
 9 files changed, 455 insertions(+)
 create mode 100644 spec/build/testsuites/psxtests/psxclocknanosleep01.yml
 create mode 100644 spec/build/testsuites/psxtmtests/psxtmclocknanosleep04.yml
 create mode 100644 spec/build/testsuites/psxtmtests/psxtmclocknanosleep05.yml
 create mode 100644 testsuites/psxtests/psxclocknanosleep01/init.c
 create mode 100644 
testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.doc
 create mode 100644 
testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.scn
 create mode 100644 testsuites/psxtmtests/psxtmclocknanosleep04/init.c
 create mode 100644 testsuites/psxtmtests/psxtmclocknanosleep05/init.c

diff --git a/spec/build/testsuites/psxtests/psxclocknanosleep01.yml 
b/spec/build/testsuites/psxtests/psxclocknanosleep01.yml
new file mode 100644
index 00..990e4a633c
--- /dev/null
+++ b/spec/build/testsuites/psxtests/psxclocknanosleep01.yml
@@ -0,0 +1,19 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+build-type: test-program
+cflags: []
+copyrights:
+- Copyright (C) 2020 Utkarsh Rai(utkarsh.ra...@gmail.com)
+cppflags: []
+cxxflags: []
+enabled-by: true
+features: c cprogram
+includes: []
+ldflags: []
+links: []
+source:
+- testsuites/psxtests/psxclocknanosleep01/init.c
+stlib: []
+target: testsuites/psxtests/psxclocknanosleep01.exe
+type: build
+use-after: []
+use-before: []
diff --git a/spec/build/testsuites/psxtmtests/grp.yml 
b/spec/build/testsuites/psxtmtests/grp.yml
index 2d4c5b2b97..409d1c45b7 100644
--- a/spec/build/testsuites/psxtmtests/grp.yml
+++ b/spec/build/testsuites/psxtmtests/grp.yml
@@ -31,6 +31,10 @@ links:
   uid: psxtmclocknanosleep02
 - role: build-dependency
   uid: psxtmclocknanosleep03
+- role: build-dependency
+  uid: psxtmclocknanosleep04
+- role: build-dependency
+  uid: psxtmclocknanosleep05
 - role: build-dependency
   uid: psxtmcond01
 - role: build-dependency
diff --git a/spec/build/testsuites/psxtmtests/psxtmclocknanosleep04.yml 
b/spec/build/testsuites/psxtmtests/psxtmclocknanosleep04.yml
new file mode 100644
index 00..12672c79ed
--- /dev/null
+++ b/spec/build/testsuites/psxtmtests/psxtmclocknanosleep04.yml
@@ -0,0 +1,19 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+build-type: test-program
+cflags: []
+copyrights:
+- Copyright (C) 2020 Utkarsh Rai (utkarsh.ra...@gmail.com)
+cppflags: []
+cxxflags: []
+enabled-by: true
+features: c cprogram
+includes: []
+ldflags: []
+links: []
+source:
+- testsuites/psxtmtests/psxtmclocknanosleep04/init.c
+stlib: []
+target: testsuites/psxtmtests/psxtmclocknanosleep04.exe
+type: build
+use-after: []
+use-before: []
diff --git a/spec/build/testsuites/psxtmtests/psxtmclocknanosleep05.yml 
b/spec/build/testsuites/psxtmtests/psxtmclocknanosleep05.yml
new file mode 100644
index 00..a3634341de
--- /dev/null
+++ b/spec/build/testsuites/psxtmtests/psxtmclocknanosleep05.yml
@@ -0,0 +1,19 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+build-type: test-program
+cflags: []
+copyrights:
+- Copyright (C) 2020 Utkarsh Rai (utkarsh.ra...@gmail.com)
+cppflags: []
+cxxflags: []
+enabled-by: true
+features: c cprogram
+includes: []
+ldflags: []
+links: []
+source:
+- testsuites/psxtmtests/psxtmclocknanosleep05/init.c
+stlib: []
+target: testsuites/psxtmtests/psxtmclocknanosleep05.exe
+type: build
+use-after: []
+use-before: []
diff --git a/testsuites/psxtests/psxclocknanosleep01/init.c 
b/testsuites/psxtests/psxclocknanosleep01/init.c
new file mode 100644
index 00..278683953c
--- /dev/null
+++ b/testsuites/psxtests/psxclocknanosleep01/init.c
@@ -0,0 +1,145 @@
+/* SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (C) 2020 Utkarsh Rai
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE 

Error while using the trace linker

[Utkarsh Rai]

Hello,
I am following the tracing example as mentioned in the docs
 for
sparc/erc32 BSP.  When I run the "rtems-tld" command, I get the following
error - "error: /home/utkarsh/sandbox/bsps/sparc: Invalid RTEMS path"

My directory structure is -
|-$HOME- | - sandbox -|- bsps -  |-sparc
 | - rtems
 | - rsb

I have used the exact command as mentioned in the example with changes made
according to my installation from the top of the BSP installation
directory. The rtems-path in the fileio-trace.ini file is set to
"$HOME/sandbox/bsps/sparc".

I know I am making a very simple mistake but  just can't seem to put my
finger on it. Can someone point what is it that I am doing wrong?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v4] Test for clock_nanosleep() with CLOCK_MONOTONIC option

[Utkarsh Rai]

On Mon, Sep 28, 2020 at 9:58 PM Gedare Bloom  wrote:

> Hi Utkarsh,
>
> I was starting to review this, but then I got a little bit confused by
> what you have done.
>
> I think you may have gone down the wrong path to do this work. It
> looks like you copied from libtests/ttest01 to construct this test.
> That is actually a test for the testing infrastructure itself. So its
> format isn't really the proper way to structure a posix clock test. I
> know there aren't a lot of examples of the TTest framework, but this
> should be structured more like one of the existing
> sptests/smptests/psxtests that is using the T_TEST_CASE().
>
> https://docs.rtems.org/branches/master/eng/test-framework.html#the-rtems-test-framework


Oh, Ok I will make the changes.


>
>
> Perhaps, restart with something simpler and send that first. Then you
> should take a look at the existing test we have for the
> clock_nanosleep() that only does CLOCK_REALTIME for some of the logic
> to test as well. It seems like you have done a pretty basic API-level
> test, but it is only checking some return values and not actually
> verifying the implementation did anything.
>

Dr. Joel suggested in the previous review
<https://lists.rtems.org/pipermail/devel/2020-April/059380.html> that this
test could be the same as clock real-time with the clock type changed but
looking
back I realize that there is much more to that test than what I have
implemented. I will change this.


>
>
> On Mon, Sep 21, 2020 at 9:15 AM Utkarsh Rai 
> wrote:
> >
> > From: Utkarsh 
> Please use full (legal) name for commit metadata
>
> >
> > Closes #3890
> >
> > Signed-off-by: Utkarsh Rai 
> > ---
> >  spec/build/testsuites/psxtests/grp.yml|   2 +
> >  .../psxtests/psxclocknanosleep01.yml  |  20 +++
> >  .../psxtests/psxclocknanosleep01/init.c   |  94 ++
> >  .../psxclocknanosleep01.doc   |  13 ++
> >  .../psxclocknanosleep01.scn   |  41 ++
> >  .../test-clock-nanosleep.c| 120 ++
> >  6 files changed, 290 insertions(+)
> >  create mode 100644
> spec/build/testsuites/psxtests/psxclocknanosleep01.yml
> >  create mode 100644 testsuites/psxtests/psxclocknanosleep01/init.c
> >  create mode 100644
> testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.doc
> >  create mode 100644
> testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.scn
> >  create mode 100644
> testsuites/psxtests/psxclocknanosleep01/test-clock-nanosleep.c
> >
> > diff --git a/spec/build/testsuites/psxtests/grp.yml
> b/spec/build/testsuites/psxtests/grp.yml
> > index 47dedac275..3342fc6c18 100644
> > --- a/spec/build/testsuites/psxtests/grp.yml
> > +++ b/spec/build/testsuites/psxtests/grp.yml
> > @@ -79,6 +79,8 @@ links:
> >uid: psxclock
> >  - role: build-dependency
> >uid: psxclock01
> > +- role: build-dependency
> > +  uid: psxclocknanosleep01
> >  - role: build-dependency
> >uid: psxclockrealtime01
> >  - role: build-dependency
> > diff --git a/spec/build/testsuites/psxtests/psxclocknanosleep01.yml
> b/spec/build/testsuites/psxtests/psxclocknanosleep01.yml
> > new file mode 100644
> > index 00..39ec1657d2
> > --- /dev/null
> > +++ b/spec/build/testsuites/psxtests/psxclocknanosleep01.yml
> > @@ -0,0 +1,20 @@
> > +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> > +build-type: test-program
> > +cflags: []
> > +copyrights:
> > +- Copyright (C) 2020 Utkarsh Rai (utkarsh.ra...@mail.com)
> > +cppflags: []
> > +cxxflags: []
> > +enabled-by: true
> > +features: c cprogram
> > +includes: []
> > +ldflags: []
> > +links: []
> > +source:
> > +- testsuites/psxtests/psxclocknanosleep01/init.c
> > +- testsuites/psxtests/psxclocknanosleep01/test-clock-nanosleep.c
> > +stlib: []
> > +target: testsuites/psxtests/psxclocknanosleep01.exe
> > +type: build
> > +use-after: []
> > +use-before: []
> > diff --git a/testsuites/psxtests/psxclocknanosleep01/init.c
> b/testsuites/psxtests/psxclocknanosleep01/init.c
> > new file mode 100644
> > index 00..a5cb4d6054
> > --- /dev/null
> > +++ b/testsuites/psxtests/psxclocknanosleep01/init.c
> > @@ -0,0 +1,94 @@
> > +/* SPDX-License-Identifier: BSD-2-Clause
> > + *
> > + * Copyright (C) 2020 Utkarsh Rai
> > + *
> > + * Redistribution and use in source and binary forms, with or without
> > + * modification, are permitted provided that the following conditions
> > + * are met:
> >

Re: [PATCH v4] Test for clock_nanosleep() with CLOCK_MONOTONIC option

[Utkarsh Rai]

Hello,
Can someone please review this. I would like to work on the suggested
changes over the weekend.

On Mon, Sep 21, 2020 at 8:45 PM Utkarsh Rai  wrote:

> From: Utkarsh 
>
> Closes #3890
>
> Signed-off-by: Utkarsh Rai 
> ---
>  spec/build/testsuites/psxtests/grp.yml|   2 +
>  .../psxtests/psxclocknanosleep01.yml  |  20 +++
>  .../psxtests/psxclocknanosleep01/init.c   |  94 ++
>  .../psxclocknanosleep01.doc   |  13 ++
>  .../psxclocknanosleep01.scn   |  41 ++
>  .../test-clock-nanosleep.c| 120 ++
>  6 files changed, 290 insertions(+)
>  create mode 100644 spec/build/testsuites/psxtests/psxclocknanosleep01.yml
>  create mode 100644 testsuites/psxtests/psxclocknanosleep01/init.c
>  create mode 100644
> testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.doc
>  create mode 100644
> testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.scn
>  create mode 100644
> testsuites/psxtests/psxclocknanosleep01/test-clock-nanosleep.c
>
> diff --git a/spec/build/testsuites/psxtests/grp.yml
> b/spec/build/testsuites/psxtests/grp.yml
> index 47dedac275..3342fc6c18 100644
> --- a/spec/build/testsuites/psxtests/grp.yml
> +++ b/spec/build/testsuites/psxtests/grp.yml
> @@ -79,6 +79,8 @@ links:
>uid: psxclock
>  - role: build-dependency
>uid: psxclock01
> +- role: build-dependency
> +  uid: psxclocknanosleep01
>  - role: build-dependency
>uid: psxclockrealtime01
>  - role: build-dependency
> diff --git a/spec/build/testsuites/psxtests/psxclocknanosleep01.yml
> b/spec/build/testsuites/psxtests/psxclocknanosleep01.yml
> new file mode 100644
> index 00..39ec1657d2
> --- /dev/null
> +++ b/spec/build/testsuites/psxtests/psxclocknanosleep01.yml
> @@ -0,0 +1,20 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +build-type: test-program
> +cflags: []
> +copyrights:
> +- Copyright (C) 2020 Utkarsh Rai (utkarsh.ra...@mail.com)
> +cppflags: []
> +cxxflags: []
> +enabled-by: true
> +features: c cprogram
> +includes: []
> +ldflags: []
> +links: []
> +source:
> +- testsuites/psxtests/psxclocknanosleep01/init.c
> +- testsuites/psxtests/psxclocknanosleep01/test-clock-nanosleep.c
> +stlib: []
> +target: testsuites/psxtests/psxclocknanosleep01.exe
> +type: build
> +use-after: []
> +use-before: []
> diff --git a/testsuites/psxtests/psxclocknanosleep01/init.c
> b/testsuites/psxtests/psxclocknanosleep01/init.c
> new file mode 100644
> index 00..a5cb4d6054
> --- /dev/null
> +++ b/testsuites/psxtests/psxclocknanosleep01/init.c
> @@ -0,0 +1,94 @@
> +/* SPDX-License-Identifier: BSD-2-Clause
> + *
> + * Copyright (C) 2020 Utkarsh Rai
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> "AS IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
> THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
> BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
> THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +const char rtems_test_name[] = "PSXCLOCKNANOSLEEP01";
> +
> +static char buffer[512];
> +
> +static const T_action actions[] = {
> +   T_report_hash_sha256,
> +   T_check_task_context,
> +   T_check_file_descriptors,
> +   T_check_rtems_barriers,
> +   T_check_rtems_extensions,
> +   T_check_rtems_message_queues,
> +   T_check_

Re: Fatal exceptions on context-switching for more than two isolated threads

[Utkarsh Rai]

On Mon, Sep 21, 2020 at 10:29 PM Gedare Bloom  wrote:

> On Sat, Sep 19, 2020 at 5:41 AM Utkarsh Rai 
> wrote:
> >
> > Hello,
> > When I isolate more than two threads in RTEMS (the implementation can be
> found here), I get fatal exceptions while context-switching. On stepping
> into the code, the problem seems to be with the _User_extensions_Thread_*()
> call  just after a context-switch, in particular when the iterators are
> initialized inside this call. The issue is the fact that we mark the stack
> space of the switched out thread as 'NO_ACESS' and then try to access
> iterators(which belong to the stack space of the switched-out thread) from
> a different thread, which leads to fatal exceptions.
> > I am not sure how to handle this issue because I am not very clear on
> the purpose of the "user extension" functionality or its implementation.
> Any help would be appreciated, as this may possibly be the last hurdle for
> a mergeable thread stack isolation feature.
>
> Are you testing in an SMP configuration? The user extensions in
> uniprocessor run before the context switch.


No, I am running with a simple uniprocessor configuration.


> It would help if you
> provide a trace of your debug.


The backtrace -

_Chain_Append_unprotected (the_chain=0x2002a0 <_User_extensions_List+12>,
the_node=0xfbf4fa0) at
../../../cpukit/include/rtems/score/chainimpl.h:694
#1  0x0010d630 in _Chain_Iterator_initialize (
the_chain=0x200294 <_User_extensions_List>,
the_registry=0x2002a0 <_User_extensions_List+12>,
the_iterator=0xfbf4fa0,
direction=CHAIN_ITERATOR_FORWARD)
at ../../../cpukit/include/rtems/score/chainimpl.h:1065
#2  0x0010d92e in _User_extensions_Iterate (
arg=0x201df8 <_POSIX_Threads_Objects+2016>,
visitor=0x10d7f5 <_User_extensions_Thread_begin_visitor>,
direction=CHAIN_ITERATOR_FORWARD)
at ../../../cpukit/score/src/userextiterate.c:184
#3  0x0010a172 in _User_extensions_Thread_begin (
executing=0x201df8 <_POSIX_Threads_Objects+2016>)
at ../../../cpukit/include/rtems/score/userextimpl.h:353
#4  0x0010a21c in _Thread_Handler ()
at ../../../cpukit/score/src/threadhandler.c:140
#5  0x0010e1e8 in _CPU_Context_switch_arm ()
at ../../../cpukit/score/cpu/arm/cpu_asm.S:121

The previous node of the chain was at 0xfbf7a0 which has been

You might consider using the event
> recorder to also help with your debugging.
> https://docs.rtems.org/branches/master/user/tracing/index.html


Ok,  I will look into it.


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

[PATCH v4] Test for clock_nanosleep() with CLOCK_MONOTONIC option

[Utkarsh Rai]

From: Utkarsh 

Closes #3890

Signed-off-by: Utkarsh Rai 
---
 spec/build/testsuites/psxtests/grp.yml|   2 +
 .../psxtests/psxclocknanosleep01.yml  |  20 +++
 .../psxtests/psxclocknanosleep01/init.c   |  94 ++
 .../psxclocknanosleep01.doc   |  13 ++
 .../psxclocknanosleep01.scn   |  41 ++
 .../test-clock-nanosleep.c| 120 ++
 6 files changed, 290 insertions(+)
 create mode 100644 spec/build/testsuites/psxtests/psxclocknanosleep01.yml
 create mode 100644 testsuites/psxtests/psxclocknanosleep01/init.c
 create mode 100644 
testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.doc
 create mode 100644 
testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.scn
 create mode 100644 
testsuites/psxtests/psxclocknanosleep01/test-clock-nanosleep.c

diff --git a/spec/build/testsuites/psxtests/grp.yml 
b/spec/build/testsuites/psxtests/grp.yml
index 47dedac275..3342fc6c18 100644
--- a/spec/build/testsuites/psxtests/grp.yml
+++ b/spec/build/testsuites/psxtests/grp.yml
@@ -79,6 +79,8 @@ links:
   uid: psxclock
 - role: build-dependency
   uid: psxclock01
+- role: build-dependency
+  uid: psxclocknanosleep01
 - role: build-dependency
   uid: psxclockrealtime01
 - role: build-dependency
diff --git a/spec/build/testsuites/psxtests/psxclocknanosleep01.yml 
b/spec/build/testsuites/psxtests/psxclocknanosleep01.yml
new file mode 100644
index 00..39ec1657d2
--- /dev/null
+++ b/spec/build/testsuites/psxtests/psxclocknanosleep01.yml
@@ -0,0 +1,20 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+build-type: test-program
+cflags: []
+copyrights:
+- Copyright (C) 2020 Utkarsh Rai (utkarsh.ra...@mail.com)
+cppflags: []
+cxxflags: []
+enabled-by: true
+features: c cprogram
+includes: []
+ldflags: []
+links: []
+source:
+- testsuites/psxtests/psxclocknanosleep01/init.c
+- testsuites/psxtests/psxclocknanosleep01/test-clock-nanosleep.c
+stlib: []
+target: testsuites/psxtests/psxclocknanosleep01.exe
+type: build
+use-after: []
+use-before: []
diff --git a/testsuites/psxtests/psxclocknanosleep01/init.c 
b/testsuites/psxtests/psxclocknanosleep01/init.c
new file mode 100644
index 00..a5cb4d6054
--- /dev/null
+++ b/testsuites/psxtests/psxclocknanosleep01/init.c
@@ -0,0 +1,94 @@
+/* SPDX-License-Identifier: BSD-2-Clause 
+ *
+ * Copyright (C) 2020 Utkarsh Rai
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+const char rtems_test_name[] = "PSXCLOCKNANOSLEEP01";
+
+static char buffer[512];
+
+static const T_action actions[] = {
+   T_report_hash_sha256,
+   T_check_task_context,
+   T_check_file_descriptors,
+   T_check_rtems_barriers,
+   T_check_rtems_extensions,
+   T_check_rtems_message_queues,
+   T_check_rtems_partitions,
+   T_check_rtems_periods,
+   T_check_rtems_regions,
+   T_check_rtems_semaphores,
+   T_check_rtems_tasks,
+   T_check_rtems_timers,
+   T_check_posix_keys
+};
+
+static const T_config config = {
+   .name = "POSIXCLOCKNANOSLEEPTEST01",
+   .buf = buffer,
+   .buf_size = sizeof( buffer ),
+   .putchar = rtems_put_char,
+   .verbosity = T_VERBOSE,
+   .now = T_now_clock,
+   .action_count = T_ARRAY_SIZE( actions ),
+   .actions = actions
+};
+
+static void
+Init( rtems_task_argument arg )
+{
+   int exit_code;
+
+   (void) arg;
+   TEST_BEGIN();
+
+   T_register();
+   exit_code = T_main(  );
+   if (exit_code == 0) {
+   TEST_END();
+ 

Fatal exceptions on context-switching for more than two isolated threads

[Utkarsh Rai]

Hello,
When I isolate more than two threads in RTEMS (the implementation can be
found here
),
I get fatal exceptions while context-switching. On stepping into the code,
the problem seems to be with the _User_extensions_Thread_*() call  just
after a context-switch, in particular when the iterators are initialized
inside this call. The issue is the fact that we mark the stack space of the
switched out thread as 'NO_ACESS' and then try to access iterators(which
belong to the stack space of the switched-out thread) from a different
thread, which leads to fatal exceptions.
I am not sure how to handle this issue because I am not very clear on the
purpose of the "user extension" functionality or its implementation. Any
help would be appreciated, as this may possibly be the last hurdle for a
mergeable thread stack isolation feature.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: devel Digest, Vol 106, Issue 81

[Utkarsh Rai]

On Mon, Sep 14, 2020 at 5:30 PM  wrote:

> Send devel mailing list submissions to
> devel@rtems.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.rtems.org/mailman/listinfo/devel
> or, via email, send a message with subject or body 'help' to
> devel-requ...@rtems.org
>
> You can reach the person managing the list at
> devel-ow...@rtems.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of devel digest..."
>
>
> Today's Topics:
>
>1. New build system ready for testing (Sebastian Huber)
>
>
> --
>
> Message: 1
> Date: Mon, 14 Sep 2020 09:07:42 +0200
> From: Sebastian Huber 
> To: RTEMS 
> Subject: New build system ready for testing
> Message-ID: <7530cecd-e1b4-b1be-af12-7593fc456...@embedded-brains.de>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hello,
>
> I checked in the new build system today. Now is a good time to test your
> favourite BSP if it still works.


Hello Sebastian, I have tested the new build system for the realview and
the xilinx_zynq_qemu BSP during my GSoC project. The config.ini file had
the options generated from "./waf bsp_defaults". The legacy stack for both
the BSPs builds successfully, the RSB build is also successful. Although I
am not sure how to run all the tests?


> You find the user oriented
> documentation of build system here:


> https://docs.rtems.org/branches/master/user/bld/index.html
>
> The documentation for RTEMS maintainers is here:
>
> https://docs.rtems.org/branches/master/eng/build-system.html
>
> How to check the new build system for a particular BSP?
>
> 1. Build the BSP with all tests enabled.
>
> 2. Run the tests and compare the results with the old build system.
> Ideally use the RTEMS Tester to run the tests and report them to the
> RTEMS Project.
>
> 3. Check if all BSP options are available (./waf bsp_defaults). Check
> the type and values of the BSP options.
>
> 4. Check the linker command file.
>
> 5. Check the compiler machine flags.
>
> 6. Install the BSP and build your third-party libraries and applications
> with it.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine gesch?ftliche Mitteilung im Sinne des EHUG.
>
>
> --
>
> Subject: Digest Footer
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
> --
>
> End of devel Digest, Vol 106, Issue 81
> **
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: How to use _Thread_Get() function properly?

[Utkarsh Rai]

Thanks, I'll check it out.

On Mon, Aug 31, 2020 at 11:35 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 31/08/2020 19:52, Utkarsh Rai wrote:
>
> > Hello,
> > I have been trying to get the pointer to the control block of a thread
> > using the _Thread_Get() function for stack sharing using a
> > shared-memory object, the implementation can be seen here
> > <
> https://github.com/ur10/rtems/blob/Final_release/cpukit/posix/src/shmopen.c#L103>.
>
> >
>
> This doesn't work. You must not obtain a mutex with disabled interrupts.
>
> For the documentation, see Doxygen markup of _Thread_Get() and
> _Objects_Get(). See also existing users of _Thread_Get().
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

How to use _Thread_Get() function properly?

[Utkarsh Rai]

Hello,
I have been trying to get the pointer to the control block of a thread
using the _Thread_Get() function for stack sharing using a shared-memory
object, the implementation can be seen here
.
The problem is when I use an operation to release/acquire a critical
resource I get the fatal error
"INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT". I suspect this is because
the interrupts are disabled during object lookup and remain disabled if an
object is found( although why it would cause the above error, that escapes
me).
Can someone please point out how should I use _Thread_Get() for my desired
operation?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020 - Final project report

[Utkarsh Rai]

Thank you for your kind guidance throughout the GSoC period. My work with
this project through is not complete and I hope to get it finally merged
upstream and keep poking around even when that is done :).

On Sun, Aug 30, 2020 at 8:46 PM Gedare Bloom  wrote:

> Looks great
>
> On Sun, Aug 30, 2020 at 4:55 AM Utkarsh Rai 
> wrote:
> >
> > I have updated my post with the help of all of your suggestions. As
> @Niteesh G. S.  said, sorry to disturb you on a weekend but please take a
> look.
> >
> > On Sat, Aug 29, 2020 at 6:03 PM Utkarsh Rai 
> wrote:
> >>
> >>
> >>
> >> On Sat, Aug 29, 2020 at 3:59 PM Hesham Almatary <
> hesham.almat...@cl.cam.ac.uk> wrote:
> >>>
> >>> Hello Utkarsh,
> >>>
> >>> Thanks for the blog post. Are there any instructions on how can
> >>> someone (maybe a future GSoC student or someone else interested) get
> >>> your code tested (with test demos) and on which platform? A HOWTO
> >>> guide/blogpost will be great.
> >>
> >>
> >> Currently no, as there are a couple more tests that I want to get
> reviewed. I will update my post according to your suggestions by today
> >>
> >>>
> >>>
> >>> On Sat, 29 Aug 2020 at 00:51, Utkarsh Rai 
> wrote:
> >>> >
> >>> >
> >>> >
> >>> > On Sat, Aug 29, 2020 at 4:18 AM Gedare Bloom 
> wrote:
> >>> >>
> >>> >> Similarly, I would like to have a consolidated set of links to "your
> >>> >> code" instead of having them woven in with the narrative and links
> to
> >>> >> blogs etc.
> >>> >>
> >>> >
> >>> > Ok, I will do that.
> >>> >
> >>> >>
> >>> >> On Thu, Aug 27, 2020 at 6:33 PM Utkarsh Rai <
> utkarsh.ra...@gmail.com> wrote:
> >>> >> >
> >>> >> > Hello,
> >>> >> > I have prepared a tentative final report for my project. You can
> view it here. Note there are few changes to be made in the report based on
> my progress this week as I am working on static initialization of PMP and
> the v5 patch for thread-stack isolation and sharing.
> >>> >> > ___
> >>> >> > 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: GSoC 2020 - Final project report

[Utkarsh Rai]

I have updated my post with the help of all of your suggestions. As @Niteesh
G. S.   said, sorry to disturb you on a weekend but
please take a look.

On Sat, Aug 29, 2020 at 6:03 PM Utkarsh Rai  wrote:

>
>
> On Sat, Aug 29, 2020 at 3:59 PM Hesham Almatary <
> hesham.almat...@cl.cam.ac.uk> wrote:
>
>> Hello Utkarsh,
>>
>> Thanks for the blog post. Are there any instructions on how can
>> someone (maybe a future GSoC student or someone else interested) get
>> your code tested (with test demos) and on which platform? A HOWTO
>> guide/blogpost will be great.
>>
>
> Currently no, as there are a couple more tests that I want to get
> reviewed. I will update my post according to your suggestions by today
>
>
>>
>> On Sat, 29 Aug 2020 at 00:51, Utkarsh Rai 
>> wrote:
>> >
>> >
>> >
>> > On Sat, Aug 29, 2020 at 4:18 AM Gedare Bloom  wrote:
>> >>
>> >> Similarly, I would like to have a consolidated set of links to "your
>> >> code" instead of having them woven in with the narrative and links to
>> >> blogs etc.
>> >>
>> >
>> > Ok, I will do that.
>> >
>> >>
>> >> On Thu, Aug 27, 2020 at 6:33 PM Utkarsh Rai 
>> wrote:
>> >> >
>> >> > Hello,
>> >> > I have prepared a tentative final report for my project. You can
>> view it here. Note there are few changes to be made in the report based on
>> my progress this week as I am working on static initialization of PMP and
>> the v5 patch for thread-stack isolation and sharing.
>> >> > ___
>> >> > 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: GSoC 2020 - Final project report

[Utkarsh Rai]

On Sat, Aug 29, 2020 at 3:59 PM Hesham Almatary <
hesham.almat...@cl.cam.ac.uk> wrote:

> Hello Utkarsh,
>
> Thanks for the blog post. Are there any instructions on how can
> someone (maybe a future GSoC student or someone else interested) get
> your code tested (with test demos) and on which platform? A HOWTO
> guide/blogpost will be great.
>

Currently no, as there are a couple more tests that I want to get reviewed.
I will update my post according to your suggestions by today


>
> On Sat, 29 Aug 2020 at 00:51, Utkarsh Rai  wrote:
> >
> >
> >
> > On Sat, Aug 29, 2020 at 4:18 AM Gedare Bloom  wrote:
> >>
> >> Similarly, I would like to have a consolidated set of links to "your
> >> code" instead of having them woven in with the narrative and links to
> >> blogs etc.
> >>
> >
> > Ok, I will do that.
> >
> >>
> >> On Thu, Aug 27, 2020 at 6:33 PM Utkarsh Rai 
> wrote:
> >> >
> >> > Hello,
> >> > I have prepared a tentative final report for my project. You can view
> it here. Note there are few changes to be made in the report based on my
> progress this week as I am working on static initialization of PMP and the
> v5 patch for thread-stack isolation and sharing.
> >> > ___
> >> > 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: GSoC 2020 - Final project report

[Utkarsh Rai]

On Sat, Aug 29, 2020 at 4:18 AM Gedare Bloom  wrote:

> Similarly, I would like to have a consolidated set of links to "your
> code" instead of having them woven in with the narrative and links to
> blogs etc.
>
>
Ok, I will do that.


> On Thu, Aug 27, 2020 at 6:33 PM Utkarsh Rai 
> wrote:
> >
> > Hello,
> > I have prepared a tentative final report for my project. You can view it
> here. Note there are few changes to be made in the report based on my
> progress this week as I am working on static initialization of PMP and the
> v5 patch for thread-stack isolation and sharing.
> > ___
> > 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

GSoC 2020 - Final project report

[Utkarsh Rai]

Hello,
I have prepared a tentative final report for my project. You can view it
here
.
Note there are few changes to be made in the report based on my progress
this week as I am working on static initialization of PMP and the v5 patch
for thread-stack isolation and sharing.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: mmap shared stack design was: [PATCH v4 1/3] Strict thread-stack isolation

[Utkarsh Rai]

On Mon, Aug 24, 2020 at 9:34 PM Gedare Bloom  wrote:

> On Sat, Aug 22, 2020 at 11:27 PM Utkarsh Rai 
> wrote:
> >
> >
> >
> > On Sat, Aug 22, 2020 at 11:32 PM Gedare Bloom  wrote:
> >>
> >> I have some comments below. I'm not that happy with the lack of design
> >> discussion during the iteration of this code. While it is a little
> >> easier to critique the code, it is also a bit wasteful because I have
> >> to also comment on stylistic problems, and when some decisions you
> >> make while coding end up not being correct or aren't easily understood
> >> during code review then you might have to spend more time recoding. It
> >> can be hard to find the balance between design and code reviews,
> >>
> >> On Sat, Aug 22, 2020 at 9:19 AM Utkarsh Rai 
> wrote:
> >> > +
> >> > +#if defined ( RTEMS_THREAD_STACK_PROTECTION )
> >> > +
> >> > +/**
> >> > + * The following defines the control block  of a shared stack. Each
> stack can have
> >> > + * different sharing attributes.
> >> > + */
> >> > +typedef struct
> >> > +{
> >> > +  /** Access flags of the shared stack */
> >> > +  uint32_t access_flags;
> >> > +  /** This is the stack address of the sharing thread*/
> >> > +  void* shared_stack_area;
> >> > +  /** Stack size of the sharing thread*/
> >> > +  size_t shared_stack_size;
> >> > +  /** This is the stack address of the target stack. Maybe this area
> is not
> >> > +   * needed but this helps in selecting the target thread during
> stack sharing.
> >> > +   */
> >> > +  void* target_stack_area;
> >> I'm confused about the difference between shared_stack_area and
> >> target_stack_area
> >>
> >> > + /** Error checking for valid target stack address. This is also
> used to
> >> > +  * distinguish between a normal mmap operation and a stack sharing
> operation.
> >> > +  */
> >> I don't really know what this means.
> >
> >
> > This is related to the mmap() call. When we share stack using mmap,  two
> of the important parameters that reference to the target thread-stack
> > and sharing thread-stack are -'void* addr' which is the address of the
> target thread stack and 'int fd' that is the file descriptor to the shared
> memory
> > object corresponding to the thread stack being shared. Now, stack
> sharing is different from a normal mmap operation in the sense that we need
> to add
> > the sharing stack attributes to the stack control structure of the
> thread that is specified by 'addr' as compared to adding it to the chain of
> mappings. To select the
> > target thread we need to iterate over all the threads, in the case we do
> not find any thread, we can proceed with our normal mmap operation
> otherwise we add the
> > sharing thread stack attribute to the stack control structure of the
> target thread. We have the _Thread_Iterate() function but it only has two
> parameters the pointer to the
> > function that performs operation during each iteration and a parameter
> related to this operation. My decision to specify the 'target_stack_area',
> the 'shared_stack_area' and 'stack_shared' in the structure
> > was so that I could squeeze in as much information to select the
> thread,  set the sharing stack parameters in the thread,  and
> validate(through stack_shared attribute) in the mmap() call that this is
> > in fact a stack-sharing operation, in a single iteration.
> >
>
> Maybe I should ask this on the mmap patch itself, but I'm more
> interested in the design than the code right now. I think I'll just
> ask a few questions:
>
> The 'sharing' stack is the stack that is getting r/w permission added
> to another thread, and the 'target' thread is the thread that is
> getting the r/w permission to access the shared stack. We should not
> really care about the 'sharing thread' or the 'target stack'?
>

If the mmap() call for sharing thread stack assumes that it is being called
from the context of the 'target thread', then no, we should not.


>
> If mmap() assumes the calling context then the executing thread is the
> "target thread" and you shouldn't have to search for it? In typical
> POSIX implementations, mmap() assumes the executing process context
> called it, but can we make the same assumption?
>
> For mmap() the 'addr' should be the 'sharing' stack's (base) address
> not the 'target' stack, because you want to be accessing the 'sharing'
> stack memory? We don't have a

Re: [PATCH v4 1/3] Strict thread-stack isolation

[Utkarsh Rai]

On Sat, Aug 22, 2020 at 11:32 PM Gedare Bloom  wrote:

> I have some comments below. I'm not that happy with the lack of design
> discussion during the iteration of this code. While it is a little
> easier to critique the code, it is also a bit wasteful because I have
> to also comment on stylistic problems, and when some decisions you
> make while coding end up not being correct or aren't easily understood
> during code review then you might have to spend more time recoding. It
> can be hard to find the balance between design and code reviews,
>
> On Sat, Aug 22, 2020 at 9:19 AM Utkarsh Rai 
> wrote:
> >
> > - These patches are based on the new build system.
> > - Allocation of  page aligned stack has been done through
> posix_memalign(),
> >   which is a hack.
> > ---
> >  .../realview-pbx-a9/mmu/bsp-set-mmu-attr.c|  90 +
> >  bsps/shared/start/stackalloc.c|  12 +-
> >  cpukit/include/rtems/score/memoryprotection.h |  83 
> >  cpukit/include/rtems/score/stack.h|  56 
> >  cpukit/include/rtems/score/stackprotection.h  |  80 +++
> >  cpukit/posix/src/shmopen.c|  61 +
> >  cpukit/score/cpu/arm/cpu_asm.S|  94 +
> >  .../score/cpu/arm/include/rtems/score/cpu.h   |   2 +-
> >  cpukit/score/src/stackprotection.c| 125 ++
> >  cpukit/score/src/threadhandler.c  |   6 +
> >  .../samples/thread_stack_protection/init.c| 114 
> >  .../thread_stack_protection.doc   |   2 +
> >  .../thread_stack_protection.scn   |  20 +++
> >  13 files changed, 743 insertions(+), 2 deletions(-)
> >  create mode 100644 bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
> >  create mode 100644 cpukit/include/rtems/score/memoryprotection.h
> >  create mode 100644 cpukit/include/rtems/score/stackprotection.h
> >  create mode 100644 cpukit/score/src/stackprotection.c
> >  create mode 100644 testsuites/samples/thread_stack_protection/init.c
> >  create mode 100644
> testsuites/samples/thread_stack_protection/thread_stack_protection.doc
> >  create mode 100644
> testsuites/samples/thread_stack_protection/thread_stack_protection.scn
> >
> > diff --git a/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
> b/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
> > new file mode 100644
> > index 00..4fba1e2b22
> > --- /dev/null
> > +++ b/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
> > @@ -0,0 +1,90 @@
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +static uint32_t translate_flags(uint32_t attr_flags)
> > +{
> > +  uint32_t flags;
> > +  uint32_t memory_attribute;
> > +
> > +  if( ( attr_flags & RTEMS_READ_WRITE ) == RTEMS_READ_WRITE ) {
> space after if
>
> > +flags |= ARMV7_MMU_READ_WRITE;
> > +  }
> > +  if ( ( attr_flags & RTEMS_READ_ONLY ) == RTEMS_READ_ONLY ) {
> > +flags |= ARMV7_MMU_READ_ONLY;
> > +  }
> > +  if ( (attr_flags & RTEMS_NO_ACCESS ) == RTEMS_NO_ACCESS ) {
>
> RTEMS_NO_ACCESS is 0. This is always true?
>
> > +flags = 0;
> > +  }
> > + /*
> > +  * Check for memory-cache operation
> > +  */
> > +  if( attr_flags & RTEMS_MEMORY_CACHED ) {
> > +flags |= ARM_MMU_SECT_TEX_0 | ARM_MMU_SECT_C | ARM_MMU_SECT_B;
> > +  }
> > +
> > +  return flags;
> > +}
> > +
> > +static rtems_status_code validate_memory( uintptr_t begin, uintptr_t
> end )
> > +{
> > +  /* We can set/unset the memory attributes of the regions between the
> bsp stack
> > +   * section and the workspace section only.
> > +   */
> > +  if( begin < bsp_section_stack_begin  || end > bsp_section_work_end ) {
> ws
>

I bang my head every time this happens.


> > +return RTEMS_INVALID_ADDRESS;
> > +  } else {
> > +return RTEMS_SUCCESSFUL;
> > +  }
> > +
> > +}
> > +
> > +rtems_status_code _Memory_protection_Set_entries(uintptr_t begin,
> size_t size, uint32_t flags)
> > +{
> > +  uintptr_t end;
> > +  rtems_interrupt_level irq_level;
> > +  uint32_t access_flags;
> > +
> > +  end = begin + size;
> > +  if( validate_memory( begin, end ) == RTEMS_SUCCESSFUL ) {
> ws
>
> you should also validate the flags requested for the memory region
>
> > +access_flags = translate_flags(flags);
> ws within function call parameter list, fix throughout
>
> > +
> > +/*
> >

[PATCH v4 1/3] Strict thread-stack isolation

[Utkarsh Rai]

ORY_CACHED ) );
+#else
   if (bsp_stack_heap.area_begin != 0) {
 stack = _Heap_Allocate(_stack_heap, size);
   }
@@ -51,6 +60,7 @@ void *bsp_stack_allocate(size_t size)
   if (stack == NULL) {
 stack = _Workspace_Allocate(size);
   }
+#endif
 
   return stack;
 }
diff --git a/cpukit/include/rtems/score/memoryprotection.h 
b/cpukit/include/rtems/score/memoryprotection.h
new file mode 100644
index 00..be4ce20b22
--- /dev/null
+++ b/cpukit/include/rtems/score/memoryprotection.h
@@ -0,0 +1,83 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSScoreMemoryprotection
+ *
+ * @brief This file provodes APIs for high-level memory protection
+ */
+
+/*
+ * Copyright (C) 2020 Utkarsh Rai
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _RTEMS_SCORE_MEMORYPROTECTION_H
+#define _RTEMS_SCORE_MEMORYPROTECTION_H
+
+#include 
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#define RTEMS_NO_ACCESS 0x00
+#define RTEMS_READ_ONLY 0x01
+#define RTEMS_WRITE_ONLY 0x02
+#define RTEMS_READ_WRITE ( RTEMS_READ_ONLY | RTEMS_WRITE_ONLY )
+#define RTEMS_MEMORY_CACHED 0x04
+
+/**
+ * @brief Define the memory access permission for the specified memory region
+ * 
+ * @param begin_addr Beginning of the memory region
+ * @param size Size of the memory region
+ * @param flag Memory access flag
+ */
+ rtems_status_code _Memory_protection_Set_entries(
+  uintptr_t begin_addr,
+  size_t size,
+  uint32_t flag
+);
+
+/**
+ * @brief Unset the memory access permission for the specified memory region
+ * This operation implicitly sets the specified memory region with 'NO_ACCESS'
+ * flag.
+ * 
+ * @param begin_addr Beginning of the memory region
+ * @param size Size of the memory region
+ */
+rtems_status_code _Memory_protection_Unset_entries(
+  uintptr_t begin_addr,
+  size_t size
+);
+
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif
\ No newline at end of file
diff --git a/cpukit/include/rtems/score/stack.h 
b/cpukit/include/rtems/score/stack.h
index df1df74867..b067d5ed1b 100644
--- a/cpukit/include/rtems/score/stack.h
+++ b/cpukit/include/rtems/score/stack.h
@@ -23,6 +23,7 @@
 #define _RTEMS_SCORE_STACK_H
 
 #include 
+#include 
 
 #ifdef __cplusplus
 extern "C" {
@@ -47,6 +48,44 @@ extern "C" {
  */
 #define STACK_MINIMUM_SIZE  CPU_STACK_MINIMUM_SIZE
 
+#if defined (RTEMS_THREAD_STACK_PROTECTION)
+/**
+ * The number of stacks that can be shared with a thread. Maybe this should be
+ * a configuration option provided in the rtems/confdefs.h?
+ */ 
+#if CONFIGURE_MAXIMUM_TASKS > 0
+#define SHARED_STACK_NUMBER  CONFIGURE_MAXIMUM_TASKS - 1
+#else
+#define SHARED_STACK_NUMBER  CONFIGURE_MAXIMUM_POSIX_THREADS - 1
+#endif
+#endif /* RTEMS_THREAD_STACK_PROTECTION */
+
+
+#if defined ( RTEMS_THREAD_STACK_PROTECTION )
+
+/**
+ * The following defines the control block  of a shared stack. Each stack can 
have
+ * different sharing attributes.
+ */
+typedef struct
+{
+  /** Access flags of the shared stack */
+  uint32_t access_flags;
+  /** This is the stack address of the sharing thread*/
+  void* shared_stack_area;
+  /** Stack size of the sharing thread*/
+  size_t shared_stack_size;
+  /** This is the stack address of the target stack. Maybe this area is not
+   * needed but this helps in selecting the target thread during stack sharing.
+   */
+  void* target_stack_area;
+ /** Error checking for valid target stack address. This is also used to
+  * distinguish between a normal mmap operation and a stack sharing operation. 
+  */
+  bool stack_shared;
+} Stack_Shared_attr;
+#endif
+
 /**
  *  The following defines the control block used to manage each stack.
  */
@@ -55,6 +94,23 @@ typedef struct {
  

[PATCH v4 2/3] High level configuration option for thread stack protection

[Utkarsh Rai]

 -Configurations options are provided by using the new-build system. Refer to 
https://ftp.rtems.org/pub/rtems/people/sebh/user.pdf,
 chapter 7,for basic setup and 
https://ftp.rtems.org/pub/rtems/people/sebh/eng.pdf(chapter 9) for the 
internals of the build system.
---
 .../arm/realview-pbx-a9/bsprealviewpbxa9.yml  |  1 +
 spec/build/cpukit/cpuopts.yml |  2 ++
 spec/build/cpukit/librtemscpu.yml |  3 +++
 .../build/cpukit/optthreadstackprotection.yml | 16 
 spec/build/testsuites/samples/grp.yml |  2 ++
 .../samples/threadstackprotection.yml | 19 +++
 6 files changed, 43 insertions(+)
 create mode 100644 spec/build/cpukit/optthreadstackprotection.yml
 create mode 100644 spec/build/testsuites/samples/threadstackprotection.yml

diff --git a/spec/build/bsps/arm/realview-pbx-a9/bsprealviewpbxa9.yml 
b/spec/build/bsps/arm/realview-pbx-a9/bsprealviewpbxa9.yml
index 2721152b93..f7d2187c66 100644
--- a/spec/build/bsps/arm/realview-pbx-a9/bsprealviewpbxa9.yml
+++ b/spec/build/bsps/arm/realview-pbx-a9/bsprealviewpbxa9.yml
@@ -57,6 +57,7 @@ links:
 source:
 - bsps/arm/realview-pbx-a9/console/console-config.c
 - bsps/arm/realview-pbx-a9/console/console-polled.c
+- bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
 - bsps/arm/realview-pbx-a9/start/bspreset.c
 - bsps/arm/realview-pbx-a9/start/bspstart.c
 - bsps/arm/realview-pbx-a9/start/bspstarthooks.c
diff --git a/spec/build/cpukit/cpuopts.yml b/spec/build/cpukit/cpuopts.yml
index 1902e543ca..f7641a5e50 100644
--- a/spec/build/cpukit/cpuopts.yml
+++ b/spec/build/cpukit/cpuopts.yml
@@ -63,6 +63,8 @@ links:
   uid: optszoff
 - role: build-dependency
   uid: optsztime
+- role: build-dependency
+  uid: optthreadstackprotection
 - role: build-dependency
   uid: optversion
 target: cpukit/include/rtems/score/cpuopts.h
diff --git a/spec/build/cpukit/librtemscpu.yml 
b/spec/build/cpukit/librtemscpu.yml
index 63a0b7dca5..9855401665 100644
--- a/spec/build/cpukit/librtemscpu.yml
+++ b/spec/build/cpukit/librtemscpu.yml
@@ -353,6 +353,7 @@ install:
   - cpukit/include/rtems/score/isrlevel.h
   - cpukit/include/rtems/score/isrlock.h
   - cpukit/include/rtems/score/memory.h
+  - cpukit/include/rtems/score/memoryprotection.h
   - cpukit/include/rtems/score/mpci.h
   - cpukit/include/rtems/score/mpciimpl.h
   - cpukit/include/rtems/score/mppkt.h
@@ -405,6 +406,7 @@ install:
   - cpukit/include/rtems/score/smplockstats.h
   - cpukit/include/rtems/score/smplockticket.h
   - cpukit/include/rtems/score/stack.h
+  - cpukit/include/rtems/score/stackprotection.h
   - cpukit/include/rtems/score/stackimpl.h
   - cpukit/include/rtems/score/states.h
   - cpukit/include/rtems/score/statesimpl.h
@@ -1509,6 +1511,7 @@ source:
 - cpukit/score/src/semaphore.c
 - cpukit/score/src/smpbarrierwait.c
 - cpukit/score/src/stackallocator.c
+- cpukit/score/src/stackprotection.c
 - cpukit/score/src/threadallocateunlimited.c
 - cpukit/score/src/thread.c
 - cpukit/score/src/threadchangepriority.c
diff --git a/spec/build/cpukit/optthreadstackprotection.yml 
b/spec/build/cpukit/optthreadstackprotection.yml
new file mode 100644
index 00..4722d9f0cb
--- /dev/null
+++ b/spec/build/cpukit/optthreadstackprotection.yml
@@ -0,0 +1,16 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-boolean: null
+- env-enable: null
+- define-condition: null
+build-type: option
+copyrights:
+- Copyright (C) 2020 Utkarsh Rai (utkarsh.ra...@gmail.com)
+default: false
+default-by-variant: []
+description: |
+  Enable the thread stack protection support
+enabled-by: true
+links: []
+name: RTEMS_THREAD_STACK_PROTECTION
+type: build
diff --git a/spec/build/testsuites/samples/grp.yml 
b/spec/build/testsuites/samples/grp.yml
index c7591dc551..3fb8d588a6 100644
--- a/spec/build/testsuites/samples/grp.yml
+++ b/spec/build/testsuites/samples/grp.yml
@@ -40,6 +40,8 @@ links:
   uid: pppd
 - role: build-dependency
   uid: ticker
+- role: build-dependency
+  uid: threadstackprotection
 - role: build-dependency
   uid: unlimited
 type: build
diff --git a/spec/build/testsuites/samples/threadstackprotection.yml 
b/spec/build/testsuites/samples/threadstackprotection.yml
new file mode 100644
index 00..a33c53d392
--- /dev/null
+++ b/spec/build/testsuites/samples/threadstackprotection.yml
@@ -0,0 +1,19 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+build-type: test-program
+cflags: []
+copyrights:
+- Copyright (C) 2020 Utkarsh Rai (utkarsh.ra...@gmail.com)
+cppflags: []
+cxxflags: []
+enabled-by: true
+features: c cprogram
+includes: []
+ldflags: []
+links: []
+source:
+- testsuites/samples/thread_stack_protection/init.c
+stlib: []
+target: testsuites/samples/thread_stack_protection.exe
+type: build
+use-after: []
+use-before: []
-- 
2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v4 3/3] Thread stack sharing

[Utkarsh Rai]

For the design details of the stack sharing mechanism please refer to the 
following post -
https://gsoc2020memoryprotection.blogspot.com/2020/08/high-level-design-and-implementation-of.html
---
 cpukit/posix/src/mmap.c   |  39 -
 cpukit/posix/src/shmopen.c|  62 +---
 .../samples/thread_stack_sharing/init.c   | 136 ++
 3 files changed, 173 insertions(+), 64 deletions(-)
 create mode 100644 testsuites/samples/thread_stack_sharing/init.c

diff --git a/cpukit/posix/src/mmap.c b/cpukit/posix/src/mmap.c
index 176c6e4fe8..1d4b65cea6 100644
--- a/cpukit/posix/src/mmap.c
+++ b/cpukit/posix/src/mmap.c
@@ -28,7 +28,27 @@
 
 #include 
 #include 
+#include 
+#include 
 
+static uint32_t mmap_flag_translate(int prot)
+{
+  int prot_read;
+  int prot_write;
+  int memory_flag;
+
+  prot_read = (prot_read & PROT_READ) == PROT_READ;
+  prot_write = (prot_write & PROT_WRITE) == PROT_WRITE;
+ 
+  if(prot_read){
+memory_flag |= ( RTEMS_READ_ONLY| RTEMS_MEMORY_CACHED );
+  }
+  if(prot_write) {
+memory_flag |= ( RTEMS_READ_WRITE | RTEMS_MEMORY_CACHED );
+  }
+
+  return memory_flag;
+}
 
 /**
  * mmap chain of mappings.
@@ -50,6 +70,9 @@ void *mmap(
   boolmap_private;
   boolis_shared_shm;
   int err;
+  uint32_t memory_flags;
+  uintptr_t shared_stack_address;
+  int status;
 
   map_fixed = (flags & MAP_FIXED) == MAP_FIXED;
   map_anonymous = (flags & MAP_ANON) == MAP_ANON;
@@ -67,7 +90,10 @@ void *mmap(
 
   /*
* We can provide read, write and execute because the memory in RTEMS does
-   * not normally have protections but we cannot hide access to memory.
+   * not normally have protections but we cannot hide access to memory. For
+   * thread-stack protection we can provide no-access option, but stacks are
+   * implicitly isolated and it makes no sense to specify no-access option for
+   * already isolated stacks.
*/
   if ( prot == PROT_NONE ) {
 errno = ENOTSUP;
@@ -292,9 +318,16 @@ void *mmap(
   free( mapping );
   return MAP_FAILED;
 }
+  /**
+* We share thread-stacks only when we have a shared memory object and map
+* shared flag set
+*/
+memory_flags = mmap_flag_translate( prot );
+status = _Stackprotection_Share_stack( mapping->addr, addr, 
len,memory_flags );
+  }
+  if(status == RTEMS_INVALID_ADDRESS ) {
+rtems_chain_append_unprotected( _mappings, >node );
   }
-
-  rtems_chain_append_unprotected( _mappings, >node );
 
   mmap_mappings_lock_release( );
 
diff --git a/cpukit/posix/src/shmopen.c b/cpukit/posix/src/shmopen.c
index 1e7fda66f8..b439592fd7 100644
--- a/cpukit/posix/src/shmopen.c
+++ b/cpukit/posix/src/shmopen.c
@@ -19,13 +19,11 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
 
 #include 
-#include 
 #include 
 #include 
 
@@ -93,61 +91,6 @@ static int shm_ftruncate( rtems_libio_t *iop, off_t length )
   return 0;
 }
 
-static int shm_stack_ftruncate ( rtems_libio_t *iop, off_t length )
-{
- int err;
- Objects_Id id;
- Objects_Name_or_id_lookup_errors obj_err;
- Thread_Control *Control;
- ISR_lock_Context lock_context;
- size_t size;
- char *name;
- POSIX_Shm_Control *shm = iop_to_shm ( iop );
-
- name = shm->Object.name.name_p;
-
- /** We assign fixed pattern of naming for thread-stacks, and treat them 
-   *  accordingly.
-   */
-  if( strncmp( name, "/taskfs/", 8) == 0 ) {
-/**
- * Obtain the object id of the thread and then get the thread control block
- * corresponding to that id. 
- */
-obj_err = _Objects_Name_to_id_u32(
-&_POSIX_Threads_Information.Objects,
-   _Objects_Build_name( name[8], name[9], name[10], name[11]),
-RTEMS_LOCAL,
-
-);
-Control = _Thread_Get( id, _context );
- if( Control != NULL ) {
-   shm->shm_object.handle = Control->Start.Initial_stack.area;
-   if( length != Control->Start.Initial_stack.size) {
- return ENOMEM;
-   }
- } else {
-   return ENOMEM;
- }
-  }else{
-
-  _Objects_Allocator_lock();
-
-  err = (*shm->shm_object.ops->object_resize)( >shm_object, length );
-
-  if ( err != 0 ) {
-_Objects_Allocator_unlock();
-rtems_set_errno_and_return_minus_one( err );
-  }
-
-  _POSIX_Shm_Update_mtime_ctime( shm );
-
-  _Objects_Allocator_unlock();
-  return 0;
-  }
-
-}
-
 static int shm_close( rtems_libio_t *iop )
 {
   POSIX_Shm_Control *shm = iop_to_shm( iop );
@@ -363,11 +306,7 @@ static const rtems_filesystem_file_handlers_r shm_handlers 
= {
   .ioctl_h = rtems_filesystem_default_ioctl,
   .lseek_h = rtems_filesystem_default_lseek,
   .fstat_h = shm_fstat,
-  #if defined ( RTEMS_THREAD_STACK_PROTECTION )
-  .ftruncate_h = shm_stack_ftruncate,
-  #else
   .ftruncate_h = shm_ftruncate,
-  #endif
   .fsync_h = rtems_filesystem_default_fsync_or_fdatasync,
   .fdatasync_h = rtems_filesystem_default_fsync_or_fdatasync,
   .fcntl_h = rtems_filesystem_default_fcntl,
@@ 

Re: Context switching through an ISR in RTEMS

[Utkarsh Rai]

On Mon, Aug 17, 2020 at 10:12 PM Gedare Bloom  wrote:

> On Mon, Aug 17, 2020 at 10:30 AM Utkarsh Rai 
> wrote:
> >
> >
> >
> > On Mon, Aug 17, 2020 at 9:24 PM Gedare Bloom  wrote:
> >>
> >> On Mon, Aug 17, 2020 at 5:53 AM Utkarsh Rai 
> wrote:
> >> >
> >> >
> >> >
> >> > On Mon, Aug 17, 2020 at 11:32 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> >> >>
> >> >> On 16/08/2020 18:09, Utkarsh Rai wrote:
> >> >>
> >> >> >
> >> >> >
> >> >> > On Sun, Aug 16, 2020 at 9:18 PM Gedare Bloom  >> >> > <mailto:ged...@rtems.org>> wrote:
> >> >> >
> >> >> > On Sat, Aug 15, 2020 at 9:03 PM Utkarsh Rai
> >> >> > mailto:utkarsh.ra...@gmail.com>>
> wrote:
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > > On Sun, Aug 16, 2020 at 6:12 AM Utkarsh Rai
> >> >> > mailto:utkarsh.ra...@gmail.com>>
> wrote:
> >> >> > >>
> >> >> > >>
> >> >> > >>
> >> >> > >> On Sat, Aug 15, 2020 at 7:26 PM Gedare Bloom <
> ged...@rtems.org
> >> >> > <mailto:ged...@rtems.org>> wrote:
> >> >> > >>>
> >> >> > >>> On Sat, Aug 15, 2020 at 6:26 AM Utkarsh Rai
> >> >> > mailto:utkarsh.ra...@gmail.com>>
> wrote:
> >> >> > >>> >
> >> >> > >>> >
> >> >> > >>> > On Thu, Aug 13, 2020 at 5:10 AM Utkarsh Rai
> >> >> > mailto:utkarsh.ra...@gmail.com>>
> wrote:
> >> >> > >>> >>
> >> >> > >>> >> Thanks, I'll check them out.
> >> >> > >>> >>
> >> >> > >>> >> On Thu, Aug 13, 2020 at 12:56 AM Gedare Bloom
> >> >> > mailto:ged...@rtems.org>> wrote:
> >> >> > >>> >>>
> >> >> > >>> >>> On Wed, Aug 12, 2020 at 11:33 AM Utkarsh Rai
> >> >> > mailto:utkarsh.ra...@gmail.com>>
> wrote:
> >> >> > >>> >>> >
> >> >> > >>> >>> > Hello,
> >> >> > >>> >>> > I have been testing my code for thread stack
> isolation
> >> >> > against various tests( Some written by me, and remaining
> already
> >> >> > present). One of the limitations that I have found is that I
> >> >> > encounter fatal errors whenever a context switch takes place
> >> >> > through an ISR. Can you please explain how the context
> switching
> >> >> > procedure works when an interrupt occurs. When I use gdb for
> >> >> > stepping through the code it asynchronously moves to context
> >> >> > switching code from the executing thread( for example psx16
> test).
> >> >> > >>> >>> > For thread stack protection, the part that deals with
> >> >> > context switching simply 'sets 'the memory entries of the heir
> >> >> > stack and 'unsets' that of the executing stack.
> >> >> > >>> >>>
> >> >> > >>> >>> There are two issues to start: interrupt stacks and
> >> >> > dispatching from an ISR.
> >> >> > >>> >>>
> >> >> > >>> >>> I think you can start by reading some of the
> documentation:
> >> >> > >>> >>>
> >> >> >
> https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#processing-an-interrupt
> >> >> > >>> >>>
> >> >> > >>> >>>
> >> >> >
> https://docs.rtems.org/branches/master/c-user/scheduling_concepts.html#dispatching-tasks
> >> >> > >>> >>>
> >> >> > >>> >>>
> >> >> >
> https://docs.rtems.org/branches/master/c-user/config/general.html#configure-interrupt-stack-size
> >> >> > >&g

Re: Context switching through an ISR in RTEMS

[Utkarsh Rai]

On Mon, Aug 17, 2020 at 9:24 PM Gedare Bloom  wrote:

> On Mon, Aug 17, 2020 at 5:53 AM Utkarsh Rai 
> wrote:
> >
> >
> >
> > On Mon, Aug 17, 2020 at 11:32 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> >>
> >> On 16/08/2020 18:09, Utkarsh Rai wrote:
> >>
> >> >
> >> >
> >> > On Sun, Aug 16, 2020 at 9:18 PM Gedare Bloom  >> > <mailto:ged...@rtems.org>> wrote:
> >> >
> >> > On Sat, Aug 15, 2020 at 9:03 PM Utkarsh Rai
> >> > mailto:utkarsh.ra...@gmail.com>> wrote:
> >> > >
> >> > >
> >> > >
> >> > > On Sun, Aug 16, 2020 at 6:12 AM Utkarsh Rai
> >> > mailto:utkarsh.ra...@gmail.com>> wrote:
> >> > >>
> >> > >>
> >> > >>
> >> > >> On Sat, Aug 15, 2020 at 7:26 PM Gedare Bloom  >> > <mailto:ged...@rtems.org>> wrote:
> >> > >>>
> >> > >>> On Sat, Aug 15, 2020 at 6:26 AM Utkarsh Rai
> >> > mailto:utkarsh.ra...@gmail.com>> wrote:
> >> > >>> >
> >> > >>> >
> >> > >>> > On Thu, Aug 13, 2020 at 5:10 AM Utkarsh Rai
> >> > mailto:utkarsh.ra...@gmail.com>> wrote:
> >> > >>> >>
> >> > >>> >> Thanks, I'll check them out.
> >> > >>> >>
> >> > >>> >> On Thu, Aug 13, 2020 at 12:56 AM Gedare Bloom
> >> > mailto:ged...@rtems.org>> wrote:
> >> > >>> >>>
> >> > >>> >>> On Wed, Aug 12, 2020 at 11:33 AM Utkarsh Rai
> >> > mailto:utkarsh.ra...@gmail.com>> wrote:
> >> > >>> >>> >
> >> > >>> >>> > Hello,
> >> > >>> >>> > I have been testing my code for thread stack isolation
> >> > against various tests( Some written by me, and remaining already
> >> > present). One of the limitations that I have found is that I
> >> > encounter fatal errors whenever a context switch takes place
> >> > through an ISR. Can you please explain how the context switching
> >> > procedure works when an interrupt occurs. When I use gdb for
> >> > stepping through the code it asynchronously moves to context
> >> > switching code from the executing thread( for example psx16 test).
> >> > >>> >>> > For thread stack protection, the part that deals with
> >> > context switching simply 'sets 'the memory entries of the heir
> >> > stack and 'unsets' that of the executing stack.
> >> > >>> >>>
> >> > >>> >>> There are two issues to start: interrupt stacks and
> >> > dispatching from an ISR.
> >> > >>> >>>
> >> > >>> >>> I think you can start by reading some of the
> documentation:
> >> > >>> >>>
> >> >
> https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#processing-an-interrupt
> >> > >>> >>>
> >> > >>> >>>
> >> >
> https://docs.rtems.org/branches/master/c-user/scheduling_concepts.html#dispatching-tasks
> >> > >>> >>>
> >> > >>> >>>
> >> >
> https://docs.rtems.org/branches/master/c-user/config/general.html#configure-interrupt-stack-size
> >> > >>> >>>
> >> > >>> >>>
> >> >
> https://docs.rtems.org/branches/master/cpu-supplement/port.html#interrupt-processing
> >> > >>> >>>
> >> > >>> >>> You can also find some material in rtems-docs.git/porting
> >> > -- I don't
> >> > >>> >>> know where that gets generated.
> >> > >>> >>>
> >> > >>> >>> Continue to ask questions, and writing blog posts.
> >> > >>> >
> >> > >>> >
> >> > >>> > So after going through the materials, I was able to
> >> > understand how an ISR is registered

Re: Context switching through an ISR in RTEMS

[Utkarsh Rai]

On Mon, Aug 17, 2020 at 11:32 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 16/08/2020 18:09, Utkarsh Rai wrote:
>
> >
> >
> > On Sun, Aug 16, 2020 at 9:18 PM Gedare Bloom  > <mailto:ged...@rtems.org>> wrote:
> >
> > On Sat, Aug 15, 2020 at 9:03 PM Utkarsh Rai
> > mailto:utkarsh.ra...@gmail.com>> wrote:
> > >
> > >
> > >
> > > On Sun, Aug 16, 2020 at 6:12 AM Utkarsh Rai
> > mailto:utkarsh.ra...@gmail.com>> wrote:
> > >>
> > >>
> > >>
> >     >> On Sat, Aug 15, 2020 at 7:26 PM Gedare Bloom  > <mailto:ged...@rtems.org>> wrote:
> > >>>
> > >>> On Sat, Aug 15, 2020 at 6:26 AM Utkarsh Rai
> > mailto:utkarsh.ra...@gmail.com>> wrote:
> > >>> >
> > >>> >
> > >>> > On Thu, Aug 13, 2020 at 5:10 AM Utkarsh Rai
> > mailto:utkarsh.ra...@gmail.com>> wrote:
> > >>> >>
> > >>> >> Thanks, I'll check them out.
> > >>> >>
> > >>> >> On Thu, Aug 13, 2020 at 12:56 AM Gedare Bloom
> > mailto:ged...@rtems.org>> wrote:
> > >>> >>>
> > >>> >>> On Wed, Aug 12, 2020 at 11:33 AM Utkarsh Rai
> > mailto:utkarsh.ra...@gmail.com>> wrote:
> > >>> >>> >
> > >>> >>> > Hello,
> > >>> >>> > I have been testing my code for thread stack isolation
> > against various tests( Some written by me, and remaining already
> > present). One of the limitations that I have found is that I
> > encounter fatal errors whenever a context switch takes place
> > through an ISR. Can you please explain how the context switching
> > procedure works when an interrupt occurs. When I use gdb for
> > stepping through the code it asynchronously moves to context
> > switching code from the executing thread( for example psx16 test).
> > >>> >>> > For thread stack protection, the part that deals with
> > context switching simply 'sets 'the memory entries of the heir
> > stack and 'unsets' that of the executing stack.
> > >>> >>>
> > >>> >>> There are two issues to start: interrupt stacks and
> > dispatching from an ISR.
> > >>> >>>
> > >>> >>> I think you can start by reading some of the documentation:
> > >>> >>>
> >
> https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#processing-an-interrupt
> > >>> >>>
> > >>> >>>
> >
> https://docs.rtems.org/branches/master/c-user/scheduling_concepts.html#dispatching-tasks
> > >>> >>>
> > >>> >>>
> >
> https://docs.rtems.org/branches/master/c-user/config/general.html#configure-interrupt-stack-size
> > >>> >>>
> > >>> >>>
> >
> https://docs.rtems.org/branches/master/cpu-supplement/port.html#interrupt-processing
> > >>> >>>
> > >>> >>> You can also find some material in rtems-docs.git/porting
> > -- I don't
> > >>> >>> know where that gets generated.
> > >>> >>>
> > >>> >>> Continue to ask questions, and writing blog posts.
> > >>> >
> > >>> >
> > >>> > So after going through the materials, I was able to
> > understand how an ISR is registered, ISR stack initialization.
> > What is still not clear to me is what are the differences between
> > dispatching a task in ISR different and  a normal context-switch?
> > >>> >
> > >>> > For example the psxsignal06 test, we wait for a signal
> > here,  on setting the breakpoint at the context switch code
> > (cpu_asm.S), after this line,  I find that the heir context stack
> > is the ISR stack. The next thread is dispatched from this ISR but
> > as soon as I unset the memory attributes of the ISR stack I get a
> > fatal error. One possible reason is that the ISR stack is not page
> > aligned and unsettling its attributes unsets nearby memory
> > regions. Is there something else that I am missing?
> >  

Re: Context switching through an ISR in RTEMS

[Utkarsh Rai]

On Sun, Aug 16, 2020 at 9:18 PM Gedare Bloom  wrote:

> On Sat, Aug 15, 2020 at 9:03 PM Utkarsh Rai 
> wrote:
> >
> >
> >
> > On Sun, Aug 16, 2020 at 6:12 AM Utkarsh Rai 
> wrote:
> >>
> >>
> >>
> >> On Sat, Aug 15, 2020 at 7:26 PM Gedare Bloom  wrote:
> >>>
> >>> On Sat, Aug 15, 2020 at 6:26 AM Utkarsh Rai 
> wrote:
> >>> >
> >>> >
> >>> > On Thu, Aug 13, 2020 at 5:10 AM Utkarsh Rai 
> wrote:
> >>> >>
> >>> >> Thanks, I'll check them out.
> >>> >>
> >>> >> On Thu, Aug 13, 2020 at 12:56 AM Gedare Bloom 
> wrote:
> >>> >>>
> >>> >>> On Wed, Aug 12, 2020 at 11:33 AM Utkarsh Rai <
> utkarsh.ra...@gmail.com> wrote:
> >>> >>> >
> >>> >>> > Hello,
> >>> >>> > I have been testing my code for thread stack isolation against
> various tests( Some written by me, and remaining already present). One of
> the limitations that I have found is that I encounter fatal errors whenever
> a context switch takes place through an ISR. Can you please explain how the
> context switching procedure works when an interrupt occurs. When I use gdb
> for stepping through the code it asynchronously moves to context switching
> code from the executing thread( for example psx16 test).
> >>> >>> > For thread stack protection,  the part that deals with context
> switching simply 'sets 'the memory entries of the heir stack and 'unsets'
> that of the executing stack.
> >>> >>>
> >>> >>> There are two issues to start: interrupt stacks and dispatching
> from an ISR.
> >>> >>>
> >>> >>> I think you can start by reading some of the documentation:
> >>> >>>
> https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#processing-an-interrupt
> >>> >>>
> >>> >>>
> https://docs.rtems.org/branches/master/c-user/scheduling_concepts.html#dispatching-tasks
> >>> >>>
> >>> >>>
> https://docs.rtems.org/branches/master/c-user/config/general.html#configure-interrupt-stack-size
> >>> >>>
> >>> >>>
> https://docs.rtems.org/branches/master/cpu-supplement/port.html#interrupt-processing
> >>> >>>
> >>> >>> You can also find some material in rtems-docs.git/porting -- I
> don't
> >>> >>> know where that gets generated.
> >>> >>>
> >>> >>> Continue to ask questions, and writing blog posts.
> >>> >
> >>> >
> >>> > So after going through the materials, I was able to understand how
> an ISR is registered, ISR stack initialization. What is still not clear to
> me is what are the differences between dispatching a task in ISR different
> and  a normal context-switch?
> >>> >
> >>> > For example the psxsignal06 test, we wait for a signal here,  on
> setting the breakpoint at the context switch code (cpu_asm.S), after this
> line,  I find that the heir context stack is the ISR stack. The next thread
> is dispatched from this ISR but as soon as I unset the memory attributes of
> the ISR stack I get a fatal error. One possible reason is that the ISR
> stack is not page aligned and unsettling its attributes unsets nearby
> memory regions. Is there something else that I am missing?
> >>> >
> >>> what else is on the same page as the ISR stack?
> >>>
> >>
> >> The idle thread stack is between 0x202e40 to 0x203e40 and the ISR stack
> is between 0x203e40 to 0x204e40. So when we unset the memory for the ISR it
> unsets between 0x203000 to 0x205000, I think this may be the problem.
> >>
> >>
> >>>
> >>> Not quite related, you'll need to also make sure to map the ISR stack
> >>> back in during ISR Handling, before using it.
> >>
> >>
> >> When the ISR gets called for the first time, it already has R/W
> permission and for subsequent context switches it's memory entry is
> accordingly set/unset.
> >
> >
> > The idle thread stack and the ISR stack are placed at these addresses
> with the BSP specific linker script as "rtemsstack.idle" and
> "rtemsstack.interrupt". So to make them page-aligned we may have to make
> changes in the lnker script.
>
> Give it a try. It should be relatively easy to hack in a couple of
> alignments.
>
> We can discuss later the correctness of that.
>

Ok, I will report how it goes.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Context switching through an ISR in RTEMS

[Utkarsh Rai]

On Sun, Aug 16, 2020 at 6:12 AM Utkarsh Rai  wrote:

>
>
> On Sat, Aug 15, 2020 at 7:26 PM Gedare Bloom  wrote:
>
>> On Sat, Aug 15, 2020 at 6:26 AM Utkarsh Rai 
>> wrote:
>> >
>> >
>> > On Thu, Aug 13, 2020 at 5:10 AM Utkarsh Rai 
>> wrote:
>> >>
>> >> Thanks, I'll check them out.
>> >>
>> >> On Thu, Aug 13, 2020 at 12:56 AM Gedare Bloom 
>> wrote:
>> >>>
>> >>> On Wed, Aug 12, 2020 at 11:33 AM Utkarsh Rai 
>> wrote:
>> >>> >
>> >>> > Hello,
>> >>> > I have been testing my code for thread stack isolation against
>> various tests( Some written by me, and remaining already present). One of
>> the limitations that I have found is that I encounter fatal errors whenever
>> a context switch takes place through an ISR. Can you please explain how the
>> context switching procedure works when an interrupt occurs. When I use gdb
>> for stepping through the code it asynchronously moves to context switching
>> code from the executing thread( for example psx16 test).
>> >>> > For thread stack protection,  the part that deals with context
>> switching simply 'sets 'the memory entries of the heir stack and 'unsets'
>> that of the executing stack.
>> >>>
>> >>> There are two issues to start: interrupt stacks and dispatching from
>> an ISR.
>> >>>
>> >>> I think you can start by reading some of the documentation:
>> >>>
>> https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#processing-an-interrupt
>> >>>
>> >>>
>> https://docs.rtems.org/branches/master/c-user/scheduling_concepts.html#dispatching-tasks
>> >>>
>> >>>
>> https://docs.rtems.org/branches/master/c-user/config/general.html#configure-interrupt-stack-size
>> >>>
>> >>>
>> https://docs.rtems.org/branches/master/cpu-supplement/port.html#interrupt-processing
>> >>>
>> >>> You can also find some material in rtems-docs.git/porting -- I don't
>> >>> know where that gets generated.
>> >>>
>> >>> Continue to ask questions, and writing blog posts.
>> >
>> >
>> > So after going through the materials, I was able to understand how an
>> ISR is registered, ISR stack initialization. What is still not clear to me
>> is what are the differences between dispatching a task in ISR different
>> and  a normal context-switch?
>> >
>> > For example the psxsignal06 test, we wait for a signal here,  on
>> setting the breakpoint at the context switch code (cpu_asm.S), after this
>> line,  I find that the heir context stack is the ISR stack. The next thread
>> is dispatched from this ISR but as soon as I unset the memory attributes of
>> the ISR stack I get a fatal error. One possible reason is that the ISR
>> stack is not page aligned and unsettling its attributes unsets nearby
>> memory regions. Is there something else that I am missing?
>> >
>> what else is on the same page as the ISR stack?
>>
>>
> The idle thread stack is between 0x202e40 to 0x203e40 and the ISR stack is
> between 0x203e40 to 0x204e40. So when we unset the memory for the ISR it
> unsets between 0x203000 to 0x205000, I think this may be the problem.
>
>
>
>> Not quite related, you'll need to also make sure to map the ISR stack
>> back in during ISR Handling, before using it.
>>
>
> When the ISR gets called for the first time, it already has R/W permission
> and for subsequent context switches it's memory entry is accordingly
> set/unset.
>

The idle thread stack and the ISR stack are placed at these addresses with
the BSP specific linker script as "rtemsstack.idle" and
"rtemsstack.interrupt". So to make them page-aligned we may have to make
changes in the lnker script.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Context switching through an ISR in RTEMS

[Utkarsh Rai]

On Sat, Aug 15, 2020 at 7:26 PM Gedare Bloom  wrote:

> On Sat, Aug 15, 2020 at 6:26 AM Utkarsh Rai 
> wrote:
> >
> >
> > On Thu, Aug 13, 2020 at 5:10 AM Utkarsh Rai 
> wrote:
> >>
> >> Thanks, I'll check them out.
> >>
> >> On Thu, Aug 13, 2020 at 12:56 AM Gedare Bloom  wrote:
> >>>
> >>> On Wed, Aug 12, 2020 at 11:33 AM Utkarsh Rai 
> wrote:
> >>> >
> >>> > Hello,
> >>> > I have been testing my code for thread stack isolation against
> various tests( Some written by me, and remaining already present). One of
> the limitations that I have found is that I encounter fatal errors whenever
> a context switch takes place through an ISR. Can you please explain how the
> context switching procedure works when an interrupt occurs. When I use gdb
> for stepping through the code it asynchronously moves to context switching
> code from the executing thread( for example psx16 test).
> >>> > For thread stack protection,  the part that deals with context
> switching simply 'sets 'the memory entries of the heir stack and 'unsets'
> that of the executing stack.
> >>>
> >>> There are two issues to start: interrupt stacks and dispatching from
> an ISR.
> >>>
> >>> I think you can start by reading some of the documentation:
> >>>
> https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#processing-an-interrupt
> >>>
> >>>
> https://docs.rtems.org/branches/master/c-user/scheduling_concepts.html#dispatching-tasks
> >>>
> >>>
> https://docs.rtems.org/branches/master/c-user/config/general.html#configure-interrupt-stack-size
> >>>
> >>>
> https://docs.rtems.org/branches/master/cpu-supplement/port.html#interrupt-processing
> >>>
> >>> You can also find some material in rtems-docs.git/porting -- I don't
> >>> know where that gets generated.
> >>>
> >>> Continue to ask questions, and writing blog posts.
> >
> >
> > So after going through the materials, I was able to understand how an
> ISR is registered, ISR stack initialization. What is still not clear to me
> is what are the differences between dispatching a task in ISR different
> and  a normal context-switch?
> >
> > For example the psxsignal06 test, we wait for a signal here,  on setting
> the breakpoint at the context switch code (cpu_asm.S), after this line,  I
> find that the heir context stack is the ISR stack. The next thread is
> dispatched from this ISR but as soon as I unset the memory attributes of
> the ISR stack I get a fatal error. One possible reason is that the ISR
> stack is not page aligned and unsettling its attributes unsets nearby
> memory regions. Is there something else that I am missing?
> >
> what else is on the same page as the ISR stack?
>
>
The idle thread stack is between 0x202e40 to 0x203e40 and the ISR stack is
between 0x203e40 to 0x204e40. So when we unset the memory for the ISR it
unsets between 0x203000 to 0x205000, I think this may be the problem.



> Not quite related, you'll need to also make sure to map the ISR stack
> back in during ISR Handling, before using it.
>

When the ISR gets called for the first time, it already has R/W permission
and for subsequent context switches it's memory entry is accordingly
set/unset.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Context switching through an ISR in RTEMS

[Utkarsh Rai]

On Thu, Aug 13, 2020 at 5:10 AM Utkarsh Rai  wrote:

> Thanks, I'll check them out.
>
> On Thu, Aug 13, 2020 at 12:56 AM Gedare Bloom  wrote:
>
>> On Wed, Aug 12, 2020 at 11:33 AM Utkarsh Rai 
>> wrote:
>> >
>> > Hello,
>> > I have been testing my code for thread stack isolation against various
>> tests( Some written by me, and remaining already present). One of the
>> limitations that I have found is that I encounter fatal errors whenever a
>> context switch takes place through an ISR. Can you please explain how the
>> context switching procedure works when an interrupt occurs. When I use gdb
>> for stepping through the code it asynchronously moves to context switching
>> code from the executing thread( for example psx16 test).
>> > For thread stack protection,  the part that deals with context
>> switching simply 'sets 'the memory entries of the heir stack and 'unsets'
>> that of the executing stack.
>>
>> There are two issues to start: interrupt stacks and dispatching from an
>> ISR.
>>
>> I think you can start by reading some of the documentation:
>>
>> https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#processing-an-interrupt
>>
>>
>> https://docs.rtems.org/branches/master/c-user/scheduling_concepts.html#dispatching-tasks
>>
>>
>> https://docs.rtems.org/branches/master/c-user/config/general.html#configure-interrupt-stack-size
>>
>>
>> https://docs.rtems.org/branches/master/cpu-supplement/port.html#interrupt-processing
>>
>> You can also find some material in rtems-docs.git/porting -- I don't
>> know where that gets generated.
>>
>> Continue to ask questions, and writing blog posts.
>>
>
So after going through the materials, I was able to understand how an ISR
is registered, ISR stack initialization. What is still not clear to me is
what are the differences between dispatching a task in ISR different and  a
normal context-switch?

For example the psxsignal06 test, we wait for a signal here
<https://git.rtems.org/rtems/tree/testsuites/psxtests/psxsignal06/init.c#n66>,
on setting the breakpoint at the context switch code (cpu_asm.S), after
this line,  I find that the heir context stack is the ISR stack. The next
thread is dispatched from this ISR but as soon as I unset the memory
attributes of the ISR stack I get a fatal error. One possible reason is
that the ISR stack is not page aligned and unsettling its attributes unsets
nearby memory regions. Is there something else that I am missing?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Strict thread-stack isolation and thread-stack sharing.

[Utkarsh Rai]

On Sat, Aug 15, 2020 at 12:39 AM Gedare Bloom  wrote:

> On Fri, Aug 14, 2020 at 9:25 AM Utkarsh Rai 
> wrote:
> >
> > Sorry for the late reply, I somehow missed the mail notification!
> >
> > On Thu, Aug 13, 2020 at 9:35 PM Gedare Bloom  wrote:
> >>
> >> On Thu, Aug 13, 2020 at 9:06 AM Utkarsh Rai 
> wrote:
> >> >
> >> > -This patch provides thread-stack isolation and thread-stack sharing
> >> >  mechanism for a POSIX thread.
> >> >
> >> Monster patch! think to yourself whether or not it makes sense to
> >> split these up. The main constraint is that every patch in the series
> >> should compile/run as they are applied.
> >
> >
> > Maybe I can break this up into 3 separate patches, stack-isolation,
> stack-sharing, and the configuration option?
> >
> >>
> >> > -The patches are based on sebastian's build-2 branch of sebastian's
> repo https://git.rtems.org/sebh
> >> >
> >> > -Configurations options are provided by using the new-build system.
> Refer to https://ftp.rtems.org/pub/rtems/people/sebh/user.pdf,
> >> >  chapter 7,for basic setup and
> https://ftp.rtems.org/pub/rtems/people/sebh/eng.pdf(chapter 9) for the
> internals of the build system.
> >> > ---
> >> >  .../realview-pbx-a9/mmu/bsp-set-mmu-attr.c|  75 ++
> >> >  bsps/shared/start/stackalloc.c|  12 +-
> >> >  .../libbsp/arm/realview-pbx-a9/Makefile.am|   3 +
> >> >  cpukit/Makefile.am|   1 +
> >> >  cpukit/headers.am |   2 +
> >> >  cpukit/include/rtems/score/memoryprotection.h |  91 
> >> >  cpukit/include/rtems/score/stack.h|  49 +++
> >> >  cpukit/include/rtems/score/stackprotection.h  |  80 +++
> >> >  cpukit/include/rtems/score/thread.h   |   1 +
> >> >  cpukit/posix/src/mmap.c   |  41 +-
> >> >  cpukit/posix/src/shmwkspace.c |  46 +-
> >> >  cpukit/score/cpu/arm/cpu_asm.S|  94 
> >> >  cpukit/score/src/stackprotection.c| 103 +
> >> >  cpukit/score/src/threadhandler.c  |   6 +
> >> >  cpukit/score/src/threadinitialize.c   |   9 ++
> >> >  .../arm/realview-pbx-a9/bsprealviewpbxa9.yml  |   1 +
> >> >  spec/build/cpukit/cpuopts.yml |   2 +
> >> >  spec/build/cpukit/librtemscpu.yml |   3 +
> >> >  .../build/cpukit/optthreadstackprotection.yml |  16 +++
> >> >  spec/build/testsuites/samples/grp.yml |   4 +
> >> >  .../samples/threadstackprotection.yml |  19 +++
> >> >  .../testsuites/samples/threadstacksharing.yml |  19 +++
> >> >  testsuites/samples/Makefile.am|  16 +++
> >> >  testsuites/samples/configure.ac   |   2 +
> >> >  .../samples/thread_stack_protection/init.c| 112 +++
> >> >  .../thread_stack_protection.doc   |   2 +
> >> >  .../thread_stack_protection.scn   |  20 +++
> >> >  .../samples/thread_stack_sharing/init.c   | 136
> ++
> >> >  28 files changed, 959 insertions(+), 6 deletions(-)
> >> >  create mode 100644 bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
> >> >  create mode 100644 cpukit/include/rtems/score/memoryprotection.h
> >> >  create mode 100644 cpukit/include/rtems/score/stackprotection.h
> >> >  create mode 100644 cpukit/score/src/stackprotection.c
> >> >  create mode 100644 spec/build/cpukit/optthreadstackprotection.yml
> >> >  create mode 100644
> spec/build/testsuites/samples/threadstackprotection.yml
> >> >  create mode 100644
> spec/build/testsuites/samples/threadstacksharing.yml
> >> >  create mode 100644 testsuites/samples/thread_stack_protection/init.c
> >> >  create mode 100644
> testsuites/samples/thread_stack_protection/thread_stack_protection.doc
> >> >  create mode 100644
> testsuites/samples/thread_stack_protection/thread_stack_protection.scn
> >> >  create mode 100644 testsuites/samples/thread_stack_sharing/init.c
> >> >
> >> > diff --git a/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
> b/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
> >> > new file mode 100644
> >> > index 00..c3b469dd2a
> >> > --- /dev/null
> >> > +++ b/bsps/a

Re: [PATCH] Strict thread-stack isolation and thread-stack sharing.

[Utkarsh Rai]

Sorry for the late reply, I somehow missed the mail notification!

On Thu, Aug 13, 2020 at 9:35 PM Gedare Bloom  wrote:

> On Thu, Aug 13, 2020 at 9:06 AM Utkarsh Rai 
> wrote:
> >
> > -This patch provides thread-stack isolation and thread-stack sharing
> >  mechanism for a POSIX thread.
> >
> Monster patch! think to yourself whether or not it makes sense to
> split these up. The main constraint is that every patch in the series
> should compile/run as they are applied.
>

Maybe I can break this up into 3 separate patches, stack-isolation,
stack-sharing, and the configuration option?


> > -The patches are based on sebastian's build-2 branch of sebastian's repo
> https://git.rtems.org/sebh
> >
> > -Configurations options are provided by using the new-build system.
> Refer to https://ftp.rtems.org/pub/rtems/people/sebh/user.pdf,
> >  chapter 7,for basic setup and
> https://ftp.rtems.org/pub/rtems/people/sebh/eng.pdf(chapter 9) for the
> internals of the build system.
> > ---
> >  .../realview-pbx-a9/mmu/bsp-set-mmu-attr.c|  75 ++
> >  bsps/shared/start/stackalloc.c|  12 +-
> >  .../libbsp/arm/realview-pbx-a9/Makefile.am|   3 +
> >  cpukit/Makefile.am|   1 +
> >  cpukit/headers.am |   2 +
> >  cpukit/include/rtems/score/memoryprotection.h |  91 
> >  cpukit/include/rtems/score/stack.h|  49 +++
> >  cpukit/include/rtems/score/stackprotection.h  |  80 +++
> >  cpukit/include/rtems/score/thread.h   |   1 +
> >  cpukit/posix/src/mmap.c   |  41 +-
> >  cpukit/posix/src/shmwkspace.c |  46 +-
> >  cpukit/score/cpu/arm/cpu_asm.S|  94 
> >  cpukit/score/src/stackprotection.c| 103 +
> >  cpukit/score/src/threadhandler.c  |   6 +
> >  cpukit/score/src/threadinitialize.c   |   9 ++
> >  .../arm/realview-pbx-a9/bsprealviewpbxa9.yml  |   1 +
> >  spec/build/cpukit/cpuopts.yml |   2 +
> >  spec/build/cpukit/librtemscpu.yml |   3 +
> >  .../build/cpukit/optthreadstackprotection.yml |  16 +++
> >  spec/build/testsuites/samples/grp.yml |   4 +
> >  .../samples/threadstackprotection.yml |  19 +++
> >  .../testsuites/samples/threadstacksharing.yml |  19 +++
> >  testsuites/samples/Makefile.am|  16 +++
> >  testsuites/samples/configure.ac   |   2 +
> >  .../samples/thread_stack_protection/init.c| 112 +++
> >  .../thread_stack_protection.doc   |   2 +
> >  .../thread_stack_protection.scn   |  20 +++
> >  .../samples/thread_stack_sharing/init.c   | 136 ++
> >  28 files changed, 959 insertions(+), 6 deletions(-)
> >  create mode 100644 bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
> >  create mode 100644 cpukit/include/rtems/score/memoryprotection.h
> >  create mode 100644 cpukit/include/rtems/score/stackprotection.h
> >  create mode 100644 cpukit/score/src/stackprotection.c
> >  create mode 100644 spec/build/cpukit/optthreadstackprotection.yml
> >  create mode 100644
> spec/build/testsuites/samples/threadstackprotection.yml
> >  create mode 100644 spec/build/testsuites/samples/threadstacksharing.yml
> >  create mode 100644 testsuites/samples/thread_stack_protection/init.c
> >  create mode 100644
> testsuites/samples/thread_stack_protection/thread_stack_protection.doc
> >  create mode 100644
> testsuites/samples/thread_stack_protection/thread_stack_protection.scn
> >  create mode 100644 testsuites/samples/thread_stack_sharing/init.c
> >
> > diff --git a/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
> b/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
> > new file mode 100644
> > index 00..c3b469dd2a
> > --- /dev/null
> > +++ b/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
> > @@ -0,0 +1,75 @@
> file header block?
>
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +static uint32_t translate_flags(uint32_t attr_flags)
> > +{
> > +  uint32_t flags;
> > +  uint32_t memory_attribute;
> > +
> > +  switch (attr_flags)
> > +  {
> > +case RTEMS_READ_WRITE:
> > + flags = ARMV7_MMU_READ_WRITE;
> > + break;
> > +
> > +case RTEMS_READ_ONLY:
> > + flags = ARMV7_MMU_READ_ONLY;
> > + break;
> > +
> > +case RTEMS_NO_ACCESS:
> > +default:
> > + flags = 0;
> > + break;
> &

[PATCH] Strict thread-stack isolation and thread-stack sharing.

[Utkarsh Rai]

diff --git a/bsps/shared/start/stackalloc.c b/bsps/shared/start/stackalloc.c
index f7cf7be0f1..6ebef4d6e5 100644
--- a/bsps/shared/start/stackalloc.c
+++ b/bsps/shared/start/stackalloc.c
@@ -44,6 +44,15 @@ void *bsp_stack_allocate(size_t size)
 {
   void *stack = NULL;
 
+#if defined (RTEMS_THREAD_STACK_PROTECTION)
+/*
+ * This is a temporary hack, we need to use _Heap_Allocate_aligned() but the 
heap
+ * intialization for bsp_stack_heap fails as bsp_section_stack_size is 0. See
+ * bsp_stack_allocate_init().
+ */
+  posix_memalign(, 4096 , size);
+  _Memory_protection_Set_entries( stack, size, ( RTEMS_READ_ONLY | 
RTEMS_MEMORY_CACHED ) );
+#else
   if (bsp_stack_heap.area_begin != 0) {
 stack = _Heap_Allocate(_stack_heap, size);
   }
@@ -51,6 +60,7 @@ void *bsp_stack_allocate(size_t size)
   if (stack == NULL) {
 stack = _Workspace_Allocate(size);
   }
+#endif
 
   return stack;
 }
@@ -62,4 +72,4 @@ void bsp_stack_free(void *stack)
   if (!ok) {
 _Workspace_Free(stack);
   }
-}
+}
\ No newline at end of file
diff --git a/c/src/lib/libbsp/arm/realview-pbx-a9/Makefile.am 
b/c/src/lib/libbsp/arm/realview-pbx-a9/Makefile.am
index d5549275be..24847c7b91 100644
--- a/c/src/lib/libbsp/arm/realview-pbx-a9/Makefile.am
+++ b/c/src/lib/libbsp/arm/realview-pbx-a9/Makefile.am
@@ -74,6 +74,9 @@ librtemsbsp_a_SOURCES += 
../../../../../../bsps/arm/shared/clock/clock-a9mpcore.
 librtemsbsp_a_SOURCES += ../../../../../../bsps/arm/shared/cache/cache-cp15.c
 librtemsbsp_a_SOURCES += 
../../../../../../bsps/arm/shared/cache/cache-v7ar-disable-data.S
 
+#MMU
+librtemsbsp_a_SOURCES += 
../../../../../../bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
+
 # Start hooks
 librtemsbsp_a_SOURCES += 
../../../../../../bsps/arm/realview-pbx-a9/start/bspstarthooks.c
 
diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index 75e119ea3c..2d50d0fdce 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -929,6 +929,7 @@ librtemscpu_a_SOURCES += score/src/schedulercbsgetserverid.c
 librtemscpu_a_SOURCES += score/src/schedulercbssetparameters.c
 librtemscpu_a_SOURCES += score/src/schedulercbsreleasejob.c
 librtemscpu_a_SOURCES += score/src/schedulercbsunblock.c
+librtemscpu_a_SOURCES += score/src/stackprotection.c
 librtemscpu_a_SOURCES += score/src/stackallocator.c
 librtemscpu_a_SOURCES += score/src/pheapallocate.c
 librtemscpu_a_SOURCES += score/src/pheapextend.c
diff --git a/cpukit/headers.am b/cpukit/headers.am
index 0bba9674cd..211e17ddf8 100644
--- a/cpukit/headers.am
+++ b/cpukit/headers.am
@@ -352,6 +352,7 @@ include_rtems_score_HEADERS += include/rtems/score/isr.h
 include_rtems_score_HEADERS += include/rtems/score/isrlevel.h
 include_rtems_score_HEADERS += include/rtems/score/isrlock.h
 include_rtems_score_HEADERS += include/rtems/score/memory.h
+include_rtems_score_HEADERS += include/rtems/score/memoryprotection.h
 include_rtems_score_HEADERS += include/rtems/score/mpci.h
 include_rtems_score_HEADERS += include/rtems/score/mpciimpl.h
 include_rtems_score_HEADERS += include/rtems/score/mppkt.h
@@ -405,6 +406,7 @@ include_rtems_score_HEADERS += 
include/rtems/score/smplockstats.h
 include_rtems_score_HEADERS += include/rtems/score/smplockticket.h
 include_rtems_score_HEADERS += include/rtems/score/stack.h
 include_rtems_score_HEADERS += include/rtems/score/stackimpl.h
+include_rtems_score_HEADERS += include/rtems/score/stackprotection.h
 include_rtems_score_HEADERS += include/rtems/score/states.h
 include_rtems_score_HEADERS += include/rtems/score/statesimpl.h
 include_rtems_score_HEADERS += include/rtems/score/status.h
diff --git a/cpukit/include/rtems/score/memoryprotection.h 
b/cpukit/include/rtems/score/memoryprotection.h
new file mode 100644
index 00..245e50313c
--- /dev/null
+++ b/cpukit/include/rtems/score/memoryprotection.h
@@ -0,0 +1,91 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSScoreMemoryprotection
+ *
+ * @brief This file provodes APIs for high-level memory protection
+ * 
+ */
+
+/*
+ * Copyright (C) 2020 Utkarsh Rai
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMA

Strict thread stack isolation and sharing

[Utkarsh Rai]

Following is the complete set of changes for thread stack isolation and
sharing.

Configuration for thread stack isolation.
> The configuration for thread stack isolation is based upon the new build
system.
> The RTEMS_THREAD_STACK_PROTECTION option needs to be specified and set to
'True'
   for enabling thread stack protection.
> I have used the realview_pbx_a9 BSP which already has support for small
pages. We need different page configuration options based upon whether the
architecture supports MMU or MPU.

Application requirements for stack sharing -
 > Naming for shared memory objects is done in the application and the name
follows a fixed naming pattern ( "/taskfs/" ), this is used to
differentiate between a normal mmap operation and a stack sharing operation.
> We need to explicitly allocate stack memory from the application for
stack sharing, and then set through pthread_attr_setstack*()
> Any application has to specify a series of repetitive steps (shm_open,
ftruncate, mmap) for sharing a particular thread-stack. Maybe this can be
wrapped under a function ((rtems_share_stack() ?) ) and we only make a call
to that function every time we have to share a thread stack.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Context switching through an ISR in RTEMS

[Utkarsh Rai]

Thanks, I'll check them out.

On Thu, Aug 13, 2020 at 12:56 AM Gedare Bloom  wrote:

> On Wed, Aug 12, 2020 at 11:33 AM Utkarsh Rai 
> wrote:
> >
> > Hello,
> > I have been testing my code for thread stack isolation against various
> tests( Some written by me, and remaining already present). One of the
> limitations that I have found is that I encounter fatal errors whenever a
> context switch takes place through an ISR. Can you please explain how the
> context switching procedure works when an interrupt occurs. When I use gdb
> for stepping through the code it asynchronously moves to context switching
> code from the executing thread( for example psx16 test).
> > For thread stack protection,  the part that deals with context switching
> simply 'sets 'the memory entries of the heir stack and 'unsets' that of the
> executing stack.
>
> There are two issues to start: interrupt stacks and dispatching from an
> ISR.
>
> I think you can start by reading some of the documentation:
>
> https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#processing-an-interrupt
>
>
> https://docs.rtems.org/branches/master/c-user/scheduling_concepts.html#dispatching-tasks
>
>
> https://docs.rtems.org/branches/master/c-user/config/general.html#configure-interrupt-stack-size
>
>
> https://docs.rtems.org/branches/master/cpu-supplement/port.html#interrupt-processing
>
> You can also find some material in rtems-docs.git/porting -- I don't
> know where that gets generated.
>
> Continue to ask questions, and writing blog posts.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] Test for clock_nanosleep with CLOCK_MONOTONIC option.

[Utkarsh Rai]

Hello Joel,
I had sent a v3 patch
https://lists.rtems.org/pipermail/devel/2020-April/059603.html, but it
somehow went unnoticed. This may need a bit of fine-tuning, and I plan to
pursue it after my GSoC ends (I have too many things on my plate right now
:))

On Thu, Aug 13, 2020 at 3:46 AM Joel Sherrill  wrote:

> What's the status of this test? The last email seems to indicate it needed
> further work before being merged.
>
> On Wed, Apr 15, 2020 at 9:16 AM Joel Sherrill  wrote:
>
>>
>>
>> On Wed, Apr 15, 2020 at 9:11 AM Gedare Bloom  wrote:
>>
>>> On Tue, Apr 14, 2020 at 10:56 PM Sebastian Huber
>>>  wrote:
>>> >
>>> > Hello Utkarsh Rai,
>>> >
>>> > do we really need a new test program for this test case? I would prefer
>>> > add it to an existing test program or add a generic POSIX test program
>>> > using the RTEMS Test Framework.
>>> >
>>> I would also recommend this, or perhaps develop a test for clock
>>> monotonic that encompasses several features (as done with clock
>>> realtime).
>>>
>>
>> In theory, the clock monotonic test could be the clock realtime one
>> reused
>> with the clock type changed. There are a few cases of doing something
>> similar.
>> The behavior is supposed to be the same for delays.
>>
>> Missing in this discussion and maybe what Gedare is hinting at is that you
>> any sleep/delay/etc type of operation is never specified as a precise
>> delay,
>> it is a minimum delay. The minimum may be set by clock tick time quantum,
>> other threads, processes, etc. The POSIX standard has precise language
>> about this for clock_nanosleep. From
>> https://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_nanosleep.html
>>
>> "The suspension time caused by this function may be longer than requested
>> because the argument value is rounded up to an integer multiple of the
>> sleep resolution, or because of the scheduling of other activity by the
>> system."
>>
>> --joel
>>
>>
>>> > On 14/04/2020 19:17, Utkarsh Rai wrote:
>>> > > This test checks for a simple 1 ns delay with clock_nanosleep with
>>> > > CLOCK_MONOTONIC.
>>> > > ---
>>> > >   testsuites/psxtests/Makefile.am   |  9 +++
>>> > >   testsuites/psxtests/configure.ac  |  1 +
>>> > >   .../psxtests/psxclocknanosleep01/init.c   | 81
>>> +++
>>> > >   .../psxclocknanosleep01.doc   | 10 +++
>>> > >   .../psxclocknanosleep01.scn   |  3 +
>>> > >   5 files changed, 104 insertions(+)
>>> > >   create mode 100644 testsuites/psxtests/psxclocknanosleep01/init.c
>>> > >   create mode 100644
>>> testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.doc
>>> > >   create mode 100644
>>> testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.scn
>>> > >
>>> > > diff --git a/testsuites/psxtests/Makefile.am
>>> b/testsuites/psxtests/Makefile.am
>>> > > index 1f9e4233ec..e3918ae7a5 100755
>>> > > --- a/testsuites/psxtests/Makefile.am
>>> > > +++ b/testsuites/psxtests/Makefile.am
>>> > > @@ -321,6 +321,15 @@ psxclockrealtime01_CPPFLAGS = $(AM_CPPFLAGS) \
>>> > >   $(TEST_FLAGS_psxclockrealtime01) $(support_includes)
>>> > >   endif
>>> > >
>>> > > +if TEST_psxclocknanosleep01
>>> > > +psx_tests += psxclocknanosleep01
>>> > > +psx_screens += psxclocknanosleep01/psxclocknanosleep01.scn
>>> > > +psx_docs += psxclocknanosleep01/psxclocknanosleep01.doc
>>> > > +psxclocknanosleep01_SOURCES = psxclocknanosleep01/init.c
>>> > > +psxclocknanosleep01_CPPFLAGS = $(AM_CPPFLAGS) \
>>> > > + $(TEST_FLAGS_psxclocknanosleep01) $(support_includes)
>>> > > +endif
>>> > > +
>>> > >   if TEST_psxconcurrency01
>>> > >   psx_tests += psxconcurrency01
>>> > >   psx_screens += psxconcurrency01/psxconcurrency01.scn
>>> > > diff --git a/testsuites/psxtests/configure.ac b/testsuites/psxtests/
>>> configure.ac
>>> > > index 139787cccb..9bfe8e2c0b 100644
>>> > > --- a/testsuites/psxtests/configure.ac
>>> > > +++ b/testsuites/psxtests/configure.ac
>>> > > @@ -75,6 +75,7 @@ RTEMS_TEST_CHECK([psxcleanup01])
>>> > >   RTEMS_TES

Context switching through an ISR in RTEMS

[Utkarsh Rai]

Hello,
I have been testing my code for thread stack isolation against various
tests( Some written by me, and remaining already present). One of the
limitations that I have found is that I encounter fatal errors whenever a
context switch takes place through an ISR. Can you please explain how the
context switching procedure works when an interrupt occurs. When I use gdb
for stepping through the code it asynchronously moves to context switching
code from the executing thread( for example psx16 test).
For thread stack protection,  the part that deals with context switching
simply 'sets 'the memory entries of the heir stack and 'unsets' that of the
executing stack.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Configuration option for thread-stack protection.

[Utkarsh Rai]

On Thu, Aug 6, 2020 at 8:34 PM Gedare Bloom  wrote:

> On Thu, Aug 6, 2020 at 6:21 AM Sebastian Huber
>  wrote:
> >
> > On 06/08/2020 14:12, Utkarsh Rai wrote:
> >
> > > Hello,
> > > The thread-stack protection needs to be configured by the user. Two of
> > > the options that need configuring during build time are -
> > > > Enabling thread stack protection ( THREAD_STACK_PROTECTION )- This
> > > is a high-level option similar to RTEMS_SMP, RTEMS_POSIX_API  etc.
> > > > Size of the MMU pages - This is a BSP specific option.
> > >  Using the new build system we can configure these by adding BSP
> > > option ( for eg. realview BSP has 'optmmusmallpages.yml'  for 4K mmu
> > > pages). Similarly, we can have 'optthreadstackprotection.yml' similar
> > > to 'optsmp.yml' for enabling thread stack protection.  Is there
> > > something else we need to do, for specifying these options?
> > >
> > > Another option that needs to be specified is the number of thread
> > > stacks that can be shared with a particular thread. This can be done
> > > by specifying this in rtems/confdefs.h and then configured by the
> > > application. I would request your opinion on this and whether this is
> > > the right manner to proceed.
> >
> > Yes, we probably need a new CPU option RTEMS_THREAD_STACK_PROTECTION or
> > similar.
> >
> +1
> Just copy one of the existing high-level switches and give it a try,
> see how it turns out.
>


Ok, I am rebasing my repo to integrate the new build system and will send
the v3 patch with these switches.


>
> > Why can't you use this option in the BSP to enable the 4KiB pages MMU?
> >
> Agreed. This one can be solved with documentation specific to the
> BSP/CPU related to how to configure it for stack protection.
>
> > With respect to the application configuration, we should consider to use
> > thread-local storage for this. TLS is well supported on ARM, SPARC,
> > PowerPC, RISC-V, and m68k.
> >
> I'm not sure if I follow this thought all the way.
>
> Would the idea be to have the application populate some data structure
> with the pointers/names of stacks it needs to access in the TLS? And
> then maybe we have something that converts that structure into an
> internal representation, something that is kind of like a page table.


> Do we have a documented way of using TLS?
>

I have the same doubt, I looked around but could not find anything that
describes a way of using TLS. We can have an array of shared stack
attributes(address, length, flags) placed in the TLS.
But how will it be different/beneficial than simply adding these attributes
to the thread-stack control block and setting/unsetting them on each
context switch?


> Gedare
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Configuration option for thread-stack protection.

[Utkarsh Rai]

Hello,
The thread-stack protection needs to be configured by the user. Two of the
options that need configuring during build time are -
> Enabling thread stack protection ( THREAD_STACK_PROTECTION )- This is a
high-level option similar to RTEMS_SMP, RTEMS_POSIX_API  etc.
> Size of the MMU pages - This is a BSP specific option.
 Using the new build system we can configure these by adding BSP option (
for eg. realview BSP has 'optmmusmallpages.yml'  for 4K mmu pages).
Similarly, we can have 'optthreadstackprotection.yml' similar to
'optsmp.yml' for enabling thread stack protection.  Is there something else
we need to do, for specifying these options?

Another option that needs to be specified is the number of thread stacks
that can be shared with a particular thread. This can be done by specifying
this in rtems/confdefs.h and then configured by the application. I would
request your opinion on this and whether this is the right manner to
proceed.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Error while building realview_pbx_a9 BSP with the new build system

[Utkarsh Rai]

Yes.

https://ftp.rtems.org/pub/rtems/people/sebh/user.pdf - For steps on using
the build system( Chapter 7).

https://ftp.rtems.org/pub/rtems/people/sebh/eng.pdf- For the internals of
the build system ( Chapter 9.), Although I don't understand everything in
this perfectly well as of yet.

On Mon, Aug 3, 2020 at 10:47 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 03/08/2020 18:32, Gedare Bloom wrote:
>
> > On Mon, Aug 3, 2020 at 10:27 AM Sebastian Huber
> >   wrote:
> >> On 03/08/2020 18:25, Gedare Bloom wrote:
> >>
> >>> On Mon, Aug 3, 2020 at 10:17 AM Utkarsh Rai
>  wrote:
> >>>> When I use the above branch I get the following error on './waf
> install ' -
> >>>>
> >>>> Build failed
> >>>> Traceback (most recent call last):
> >>>> File
> "/home/utkarsh/new_build/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Task.py",
> line 180, in process
> >>>>   ret=self.run()
> >>>> File
> "/home/utkarsh/new_build/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Build.py",
> line 554, in run
> >>>>   x.parent.mkdir()
> >>>> File
> "/home/utkarsh/new_build/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Node.py",
> line 179, in mkdir
> >>>>   self.parent.mkdir()
> >>>> File
> "/home/utkarsh/new_build/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Node.py",
> line 179, in mkdir
> >>>>   self.parent.mkdir()
> >>>> File
> "/home/utkarsh/new_build/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Node.py",
> line 179, in mkdir
> >>>>   self.parent.mkdir()
> >>>> File
> "/home/utkarsh/new_build/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Node.py",
> line 179, in mkdir
> >>>>   self.parent.mkdir()
> >>>> File
> "/home/utkarsh/new_build/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Node.py",
> line 179, in mkdir
> >>>>   self.parent.mkdir()
> >>>> File
> "/home/utkarsh/new_build/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Node.py",
> line 188, in mkdir
> >>>>   raise Errors.WafError('Could not create the directory %r'%self)
> >>>> WafError: Could not create the directory /opt/rtems
> >>>>
> >>> Most likely you don't have a /opt/rtems directory, and that is being
> >>> used as a default prefix for install. Try to set the prefix/install
> >>> point yourself to a directory you 'own' already.
> >>>
> >>> The other option is to create /opt/rtems, and chown to your user, e.g.,
> >>>
> >>> sudo mkdir /opt/rtems
> >>> sudo chown utkarsh:utkarsh /opt/rtems
> >>>
> >>> this works fine for single-user *nix development
> >>>
> >> I think we should cover this somehow in the documentation. This looks
> >> like a common issue for someone using this for the first time.
> > We have something:
> > https://docs.rtems.org/branches/master/user/start/prefixes.html
> >
> > But probably that will be skipped by a lot of people looking for a
> > "Quicker" start.
> Utkarsh, did look look at some documentation before you started to use
> the new build system?
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Error while building realview_pbx_a9 BSP with the new build system

[Utkarsh Rai]

On Mon, Aug 3, 2020 at 9:56 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 03/08/2020 18:17, Utkarsh Rai wrote:
>
> > When I use the above branch I get the following error on './waf
> > install ' -
> >
> > Build failed
> > Traceback (most recent call last):
> >   File
> >
> "/home/utkarsh/new_build/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Task.py",
>
> > line 180, in process
> > ret=self.run()
> >   File
> >
> "/home/utkarsh/new_build/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Build.py",
>
> > line 554, in run
> > x.parent.mkdir()
> >   File
> >
> "/home/utkarsh/new_build/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Node.py",
>
> > line 179, in mkdir
> > self.parent.mkdir()
> >   File
> >
> "/home/utkarsh/new_build/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Node.py",
>
> > line 179, in mkdir
> > self.parent.mkdir()
> >   File
> >
> "/home/utkarsh/new_build/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Node.py",
>
> > line 179, in mkdir
> > self.parent.mkdir()
> >   File
> >
> "/home/utkarsh/new_build/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Node.py",
>
> > line 179, in mkdir
> > self.parent.mkdir()
> >   File
> >
> "/home/utkarsh/new_build/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Node.py",
>
> > line 179, in mkdir
> > self.parent.mkdir()
> >   File
> >
> "/home/utkarsh/new_build/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Node.py",
>
> > line 188, in mkdir
> > raise Errors.WafError('Could not create the directory %r'%self)
> > WafError: Could not create the directory /opt/rtems
>
> This is good, since it shows that you build as a normal user and not as
> root.
>
> Did you read the documentation of the new build system?
>

Sorry, I forgot about that part. It builds now.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Design issues with thread-stack isolation/sharing.

[Utkarsh Rai]

On Mon, Aug 3, 2020 at 9:35 PM Gedare Bloom  wrote:

> On Sun, Aug 2, 2020 at 5:46 AM Utkarsh Rai 
> wrote:
> >
> >
> >
> > On Sat, Aug 1, 2020 at 10:51 PM Gedare Bloom  wrote:
> >>
> >> On Sat, Aug 1, 2020 at 10:38 AM Utkarsh Rai 
> wrote:
> >> >
> >> > This thread is an attempt to consolidate and resolve all the issues
> that have been raised related to my patches- 1.
> https://lists.rtems.org/pipermail/devel/2020-July/060675.html and 2.
> https://lists.rtems.org/pipermail/devel/2020-July/061056.html. I intend
> to first resolve all the issues through this thread( and probably convert
> this into a blog-post ), before making any further changes.
> >> >
> >> > 1. Stack address name that needs to be passed to shm_open() - This
> was briefly discussed here, and I believe the reason we still have issues
> with this is because of my incorrect interpretation of what was suggested.
> My idea was that we need to assign a name like "/taskfs/pid" to each stack
> address on the creation of the thread. On looking around further, I realize
> we can have the stack address name the same as the thread name.
> >> >
> >> ok. the /taskfs idea was more of a longer-term concept. I think it
> >> would require possibly an entire GSoC itself. It'd be nice though :)
> >>
> >> > 2. Switching out shared stacks- In my current implementation,
> removing protected stacks is done through assembly code but the
> '_Stackprotection_Context_switch' which switches out the shared stack is
> difficult to implement in assembly. But we need to integrate the shared
> stack switching in the context switching code as we don't have access to
> executing thread attributes anywhere else.
> >> >
> >> I think the real problem here is that your code to switch stacks is
> >> too complicated. It would certainly be folly to try to implement
> >> linked list processing in assembly of the context switch, but you
> >> shouldn't need to be walking a linked list anyway. There are simpler
> >> solutions that would work just as well, including replacing the entire
> >> address space (e.g., switching the page table base register) or using
> >> an array to store the shared stack addresses and just iterating the
> >> array.
> >
> >
> > Ok, but this would mean that we can only share a set number of stacks
> with each thread?
> >
>
> Perhaps. You might be able to use an extendable array if the number of
> shared stacks is configurable. This again goes into the problem that
> configuration hasn't been solved yet.
>

Ok, I will do this with a fixed array for now. I have started to try out
the new build system and most probably try to resolve the configuration
issue this week


>
> >>
> >>
> >> > 3. Integration of the 'Stackprotection_attr' structure with the
> thread and stack control structure - The integration is a pretty
> straightforward task, the difficulty lies in handling the attribute offset
> in the assembly code, whereas having the 'Stackprotection_attr'  just after
> the context control attribute in the thread control structure makes
> handling the offset relatively easy.
> >> >
> >> The Stack_Control is embedded already, you just need to calculate the
> >> location of Thread_Control.Start.Initial_stack first, and then offset
> >> within that structure.
> >
> >
> > I agree it's just that it is extra work and maybe I was being lazy :).
>
> Maybe. Sometimes it is better to pay now than later though.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Error while building realview_pbx_a9 BSP with the new build system

[Utkarsh Rai]

When I use the above branch I get the following error on './waf install ' -

Build failed
Traceback (most recent call last):
  File
"/home/utkarsh/new_build/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Task.py",
line 180, in process
ret=self.run()
  File
"/home/utkarsh/new_build/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Build.py",
line 554, in run
x.parent.mkdir()
  File
"/home/utkarsh/new_build/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Node.py",
line 179, in mkdir
self.parent.mkdir()
  File
"/home/utkarsh/new_build/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Node.py",
line 179, in mkdir
self.parent.mkdir()
  File
"/home/utkarsh/new_build/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Node.py",
line 179, in mkdir
self.parent.mkdir()
  File
"/home/utkarsh/new_build/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Node.py",
line 179, in mkdir
self.parent.mkdir()
  File
"/home/utkarsh/new_build/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Node.py",
line 179, in mkdir
self.parent.mkdir()
  File
"/home/utkarsh/new_build/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Node.py",
line 188, in mkdir
raise Errors.WafError('Could not create the directory %r'%self)
WafError: Could not create the directory /opt/rtems

On Mon, Aug 3, 2020 at 9:42 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 03/08/2020 16:41, Utkarsh Rai wrote:
>
> > Hello,
> > I have been trying out the new build system. Unfortunately, while
> > building for the realview_pbx_a9 BSP I get the following error on '
> > ./waf install '  -
> >
> > "
> > Waf: Entering directory `/home/utkarsh/new_build/rtems/build'
> > Waf: Leaving directory `/home/utkarsh/new_build/rtems/build'
> > 'install' finished successfully (0.289s)
> > Waf: Entering directory
> > `/home/utkarsh/new_build/rtems/build/arm/realview_pbx_a9_qemu'
> > Waf: Leaving directory
> > `/home/utkarsh/new_build/rtems/build/arm/realview_pbx_a9_qemu'
> >
> > source not found: 'cpukit/include/rtems/system.h' in bld(target='',
> > idx=59, install_task=
> >  {task 139909380107600: inst  -> }, dest='${BSP_INCLUDEDIR}/rtems',
> > tg_idx_count=59, meths=['process_install_task', 'process_rule',
> > 'process_source'], _name='', source=[],
> > install_to='${BSP_INCLUDEDIR}/rtems',
> > path=/home/utkarsh/new_build/rtems,
> > install_from=['cpukit/include/rtems/assoc.h'
> > [...]
> > "
> > My config.ini file has all the contents of  './waf bsp_defaults
> > --rtems-bsps=arm/realview_pbx_a9'. Can you please point out my mistake?
> I stopped to maintain the build branch.
>
> Could you please use this branch:
>
> https://git.rtems.org/sebh/rtems.git/log/?h=build-2
>
> Using the new build system in the current state is not really advisable.
> I will do forced pushes to the build-2 branch.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Error while building realview_pbx_a9 BSP with the new build system

[Utkarsh Rai]

Hello,
I have been trying out the new build system. Unfortunately, while
building for the realview_pbx_a9 BSP I get the following error on ' ./waf
install '  -

"
Waf: Entering directory `/home/utkarsh/new_build/rtems/build'
Waf: Leaving directory `/home/utkarsh/new_build/rtems/build'
'install' finished successfully (0.289s)
Waf: Entering directory
`/home/utkarsh/new_build/rtems/build/arm/realview_pbx_a9_qemu'
Waf: Leaving directory
`/home/utkarsh/new_build/rtems/build/arm/realview_pbx_a9_qemu'

source not found: 'cpukit/include/rtems/system.h' in bld(target='', idx=59,
install_task=
 {task 139909380107600: inst  -> }, dest='${BSP_INCLUDEDIR}/rtems',
tg_idx_count=59, meths=['process_install_task', 'process_rule',
'process_source'], _name='', source=[],
install_to='${BSP_INCLUDEDIR}/rtems', path=/home/utkarsh/new_build/rtems,
install_from=['cpukit/include/rtems/assoc.h'
[...]
"
My config.ini file has all the contents of  './waf bsp_defaults
--rtems-bsps=arm/realview_pbx_a9'. Can you please point out my mistake?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Design issues with thread-stack isolation/sharing.

[Utkarsh Rai]

On Sat, Aug 1, 2020 at 10:51 PM Gedare Bloom  wrote:

> On Sat, Aug 1, 2020 at 10:38 AM Utkarsh Rai 
> wrote:
> >
> > This thread is an attempt to consolidate and resolve all the issues that
> have been raised related to my patches- 1.
> https://lists.rtems.org/pipermail/devel/2020-July/060675.html and 2.
> https://lists.rtems.org/pipermail/devel/2020-July/061056.html. I intend
> to first resolve all the issues through this thread( and probably convert
> this into a blog-post ), before making any further changes.
> >
> > 1. Stack address name that needs to be passed to shm_open() - This was
> briefly discussed here, and I believe the reason we still have issues with
> this is because of my incorrect interpretation of what was suggested. My
> idea was that we need to assign a name like "/taskfs/pid" to each stack
> address on the creation of the thread. On looking around further, I realize
> we can have the stack address name the same as the thread name.
> >
> ok. the /taskfs idea was more of a longer-term concept. I think it
> would require possibly an entire GSoC itself. It'd be nice though :)
>
> > 2. Switching out shared stacks- In my current implementation, removing
> protected stacks is done through assembly code but the
> '_Stackprotection_Context_switch' which switches out the shared stack is
> difficult to implement in assembly. But we need to integrate the shared
> stack switching in the context switching code as we don't have access to
> executing thread attributes anywhere else.
> >
> I think the real problem here is that your code to switch stacks is
> too complicated. It would certainly be folly to try to implement
> linked list processing in assembly of the context switch, but you
> shouldn't need to be walking a linked list anyway. There are simpler
> solutions that would work just as well, including replacing the entire
> address space (e.g., switching the page table base register) or using
> an array to store the shared stack addresses and just iterating the
> array.
>

Ok, but this would mean that we can only share a set number of stacks with
each thread?


>
> > 3. Integration of the 'Stackprotection_attr' structure with the thread
> and stack control structure - The integration is a pretty straightforward
> task, the difficulty lies in handling the attribute offset in the assembly
> code, whereas having the 'Stackprotection_attr'  just after the context
> control attribute in the thread control structure makes handling the offset
> relatively easy.
> >
> The Stack_Control is embedded already, you just need to calculate the
> location of Thread_Control.Start.Initial_stack first, and then offset
> within that structure.
>

I agree it's just that it is extra work and maybe I was being lazy :).
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Design issues with thread-stack isolation/sharing.

[Utkarsh Rai]

This thread is an attempt to consolidate and resolve all the issues that
have been raised related to my patches- 1.
https://lists.rtems.org/pipermail/devel/2020-July/060675.html and 2.
https://lists.rtems.org/pipermail/devel/2020-July/061056.html. I intend to
first resolve all the issues through this thread( and probably convert this
into a blog-post ), before making any further changes.

1. Stack address name that needs to be passed to shm_open() - This was
briefly discussed here
, and I
believe the reason we still have issues with this is because of my
incorrect interpretation of what was suggested. My idea was that we need to
assign a name like "/taskfs/pid" to each stack address on the creation of
the thread. On looking around further, I realize we can have the stack
address name the same as the thread name.

2. Switching out shared stacks- In my current implementation, removing
protected stacks is done through assembly code

but the '_Stackprotection_Context_switch' which switches out the shared
stack is difficult to implement in assembly. But we need to integrate the
shared stack switching in the context switching code as we don't have
access to executing thread attributes anywhere else.

3. Integration of the 'Stackprotection_attr' structure with the thread and
stack control structure - The integration is a pretty straightforward task,
the difficulty lies in handling the attribute offset in the assembly code,
whereas having the 'Stackprotection_attr'  just after the context control
attribute in the thread control structure makes handling the offset
relatively easy.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] Strict thread-stack isolation and thread-stack sharing.

[Utkarsh Rai]

lude/rtems/score/memoryprotection.h 
b/cpukit/include/rtems/score/memoryprotection.h
new file mode 100644
index 00..cc01f8ba9b
--- /dev/null
+++ b/cpukit/include/rtems/score/memoryprotection.h
@@ -0,0 +1,82 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSScoreMemoryprotection
+ *
+ * @brief This file provodes APIs for high-level memory protection
+ * 
+ */
+
+/*
+ * Copyright (C) 2020 Utkarsh Rai
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _RTEMS_SCORE_MEMORYPROTECTION_H
+#define _RTEMS_SCORE_MEMORYPROTECTION_H
+
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#define NO_ACCESS 0x00
+#define READ_ONLY 0x01
+#define READ_WRITE 0x02
+#define MEMORY_CACHED 0x04
+
+/**
+ * @brief Define the memory access permission for the specified memory region
+ * 
+ * @param begin_addr Beginning of the memory region
+ * @param size Size of the memory region
+ * @param flag Memory access flag
+ * 
+ */
+void _Memory_protection_Set_entries(
+  uintptr_t begin_addr,
+  size_t size,
+  uint32_t flag
+);
+
+/**
+ * @brief Unset the memory access permission for the specified memory region
+ * This operation implicitly sets the specified memory region with 'NO_ACCESS'
+ * flag.
+ * 
+ * @param begin_addr Begining of the memory region
+ * @param size Size of the memory region
+ */
+void _Memory_protection_Unset_entries(
+  uintptr_t begin_addr,
+  size_t size
+);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif
\ No newline at end of file
diff --git a/cpukit/include/rtems/score/stackprotection.h 
b/cpukit/include/rtems/score/stackprotection.h
new file mode 100644
index 00..60893da008
--- /dev/null
+++ b/cpukit/include/rtems/score/stackprotection.h
@@ -0,0 +1,151 @@
+/**
+ * @file
+ *
+ * @ingroup RTEMSScoreStackprotection
+ *
+ * @brief Stackprotection API
+ *
+ * This include file provides the API for the management of protected thread-
+ * stacks
+ */
+
+/*
+ *  COPYRIGHT (c) 2020 Utkarsh Rai.
+ * 
+ * Redistribution and use in source and binary forms, with or without 
+ * modification, are permitted provided that the following conditions 
+ * are met: 
+ * 1. Redistributions of source code must retain the above copyright 
+ * notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright 
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * 
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" 
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE 
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR 
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF 
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS 
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN 
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) 
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 
+ * POSSIBILITY OF SUCH DAMAGE.
+ * 
+ */
+
+#ifndef _RTEMS_SCORE_STACKPROTECTION_H
+#define _RTEMS_SCORE_STACKPROTECTION_H
+
+#if defined ( ASM )
+  #include 
+#else
+  #include 
+  #include 
+  #include 
+  #include 
+#endif
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#if !defined ( ASM )
+
+/**
+ * The following defines the attributes of a protected stack
+ */
+typedef struct
+{  
+  /*

Re: Translation table for small pages in ARMv7 MMU conflicting with other data regions

[Utkarsh Rai]

Thanks, I'll check it out.

On Wed, Jul 29, 2020 at 9:36 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 29/07/2020 18:02, Utkarsh Rai wrote:
>
> > The translation table for ARMv7 MMU starts at 0x10 and extends up
> > to 0x104000 for section-based pages. Although for small pages it
> > extends up to 0x504000 this possibly conflicts with other data regions
> > and setting up of translation table for smaller pages fails.
> > I realize that various data regions are placed at specified addresses
> > by linker scripts statically. One possible solution can be to replace the
> > 'pt = [ARM_MMU_TRANSLATION_TABLE_ENTRY_COUNT]', where pt is the
> > second-level page table base-address, with another address region,
> > although I am not sure which. Can you please point the right way to
> > proceed?
> For an example please have a look at the realview_pbx_a9_qemu BSP. It
> uses 4KiB pages. With the new build system it would be easier to set up.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Translation table for small pages in ARMv7 MMU conflicting with other data regions

[Utkarsh Rai]

The translation table for ARMv7 MMU starts at 0x10 and extends up to
0x104000 for section-based pages. Although for small pages it extends up to
0x504000 this possibly conflicts with other data regions and setting up of
translation table for smaller pages fails.
I realize that various data regions are placed at specified addresses by
linker scripts statically. One possible solution can be to replace the
'pt = [ARM_MMU_TRANSLATION_TABLE_ENTRY_COUNT]', where pt is the
second-level page table base-address, with another address region,
although I am not sure which. Can you please point the right way to proceed?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Segmentation fault whie setting up translation table for small pages in ARMv7 MMU

[Utkarsh Rai]

On Sun, Jul 26, 2020 at 9:12 PM Hesham Almatary <
hesham.almat...@cl.cam.ac.uk> wrote:

>
>
> On Sun, Jul 26, 2020 at 2:04 PM Utkarsh Rai 
> wrote:
>
>> Hello,
>> I was facing issues while changing the memory entries for a section. The
>> thread can be viewed here
>> <https://lists.rtems.org/pipermail/devel/2020-July/060884.html>. The
>> error is most probably due to the fact that while I change the memory entry
>> of my desired region it ends up changing the memory permission of the
>> entire 1Mb section, which causes fatal errors.
>> To prevent this, I decided to set up translation table entries in
>> small-page format.
>>
> To do so, you need multi-level page tables for 4K pages. I doubt you’ve
> added support to do so.
>
>
I agree I am having trouble while setting up the 4K pages statically.


> You also want to make sure that your block of memory isn’t already part of
> an ELF section that is already statically mapped at boot time.
>
>

Ok, I will take care of that.


> Unfortunately, during the static initialization of the translation table,
>> the qemu hangs up (I am using Xilinx-zynq BSP). On stepping through the
>> debugger I encounter a segmentation fault.
>> Can someone please point me in the right direction? This is the final
>> issue that I have to resolve before I send my patches.
>> ___
>> 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

Segmentation fault whie setting up translation table for small pages in ARMv7 MMU

[Utkarsh Rai]

Hello,
I was facing issues while changing the memory entries for a section. The
thread can be viewed here
. The error
is most probably due to the fact that while I change the memory entry of my
desired region it ends up changing the memory permission of the entire 1Mb
section, which causes fatal errors.
To prevent this, I decided to set up translation table entries in
small-page format. Unfortunately, during the static initialization of the
translation table, the qemu hangs up (I am using Xilinx-zynq BSP). On
stepping through the debugger I encounter a segmentation fault.
Can someone please point me in the right direction? This is the final issue
that I have to resolve before I send my patches.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Fatal exception while changing the memory entries in ARMv7 MMU

[Utkarsh Rai]

Your advice worked, but not in the way it was supposed to (or maybe I
didn't do it right). I got a fatal exception even when I used the aligned
attribute. However, when I allocate memory using posix_memalign() I get the
desired result.

On Sat, Jul 25, 2020 at 9:45 PM Gedare Bloom  wrote:

> On Sat, Jul 25, 2020 at 9:44 AM Utkarsh Rai 
> wrote:
> >
> > Hello,
> > While changing the memory entries for a section in the ARMv7 MMU using
> 'arm_cp15_set_translation_table_entries()' I get fatal exception error. On
> stepping through the debugger, the exception occurs when invalidating the
> data TLB entries, using 'arm_cp15_tlb_data_invalidate_entry()'.
> >
> > You can view the relevant snippet here. Interestingly enough, the fatal
> exception occurs when I change the memory attribute from READ/WRITE to READ
> ONLY. Can someone point out my mistake?
>
> My best guess: The block of memory you pass is in global space. It is
> not likely to be page aligned. So when you change to read-only, you
> probably change some other global variables to read-only also, and
> then something tries to write to them.
>
> To see if that is the problem, use the aligned() attribute (we have
> RTEMS_ALIGNED) with the page size.
>
> > ___
> > 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

Fatal exception while changing the memory entries in ARMv7 MMU

[Utkarsh Rai]

Hello,
While changing the memory entries for a section in the ARMv7 MMU using
'arm_cp15_set_translation_table_entries()' I get fatal exception error. On
stepping through the debugger, the exception occurs when invalidating the
data TLB entries, using 'arm_cp15_tlb_data_invalidate_entry()'.

You can view the relevant snippet here
.
Interestingly enough, the fatal exception occurs when I change the memory
attribute from READ/WRITE to READ ONLY. Can someone point out my mistake?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC: Correct placement and naming of memory protection APIs

[Utkarsh Rai]

On Sat, Jul 18, 2020 at 1:21 PM Hesham Almatary <
hesham.almat...@cl.cam.ac.uk> wrote:

> We have already discussed and done that during my 2013 GSoC. Have a
> look at [1, 2] and their calls.
>
> [1]
> https://github.com/heshamelmatary/rtems-gsoc2013/blob/low-level-libmm/cpukit/score/include/rtems/score/mmimpl.h
> [2]
> https://github.com/heshamelmatary/rtems-gsoc2013/blob/low-level-libmm/cpukit/score/include/rtems/score/mm.h


While designing my interface I went through this and my model is almost
similar to yours :). My doubt is, what are the rationales for placing this
in the score? (If you look into my commit history, I have fiddled with the
placement quite a bit without any resolution).


>
>
> On Fri, 17 Jul 2020 at 21:33, Utkarsh Rai  wrote:
> >
> > Hello,
> > In RTEMS each set of BSP has its own MMU implementation, for utilizing
> this for high-level operations such as thread-stack protection we need a
> common interface that is implemented for each BSP but is available for
> high-level operations ( Something along the lines of the cache manager ),
> my current implementation can be viewed here and here  My question is, what
> should be the correct placement of these APIs and hence there naming? Can
> we model it based on the cache-manager (rtems_memory_protection_xx_xx)?
> >
> > ___
> > 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

GSoC: Correct placement and naming of memory protection APIs

[Utkarsh Rai]

Hello,
In RTEMS each set of BSP has its own MMU implementation, for utilizing this
for high-level operations such as thread-stack protection we need a common
interface that is implemented for each BSP but is available for high-level
operations ( Something along the lines of the cache manager ), my current
implementation can be viewed here

and
here

My question is, what should be the correct placement of these APIs and
hence there naming? Can we model it based on the cache-manager
(rtems_memory_protection_xx_xx)?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSoC: Disabling interrupts while modifying translation table entries for armv7-A MMU.

[Utkarsh Rai]

Hello,
The translation table setting code has _ARM_Data_synchronization_barrier()
before and after invalidating the instruction and data TLB entry, this
ensures synchronization of instructions for the TLB invalidation in case of
multiple cores. My question is, do we have to explicitly disable interrupts
too while modifying the translation table entries? The ARM reference manual
is not very clear on this topic.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] Strict thread-stack isolation

[Utkarsh Rai]

On Fri, Jul 17, 2020 at 11:08 AM Gedare Bloom  wrote:

> Is this code working? how do you test it?
>
> There are several points buried below that you might need to bring out
> to separate threads for discussion, while you work on the code.
>
> On Thu, Jul 16, 2020 at 5:34 AM Utkarsh Rai 
> wrote:
> >
> > - This is the complete set of changes for strict isolation of thread
> stacks.
> > - There needs to be a confiuration operation,(#if
> defined(USE_THREAD_STACK_PROTECTION) for simple configuration can be used)
> > - The stack attributes are allocated through malloc, this needs to be
> done through score unlimited objects.
> >
> > Mechanism for thread-stack isolation
> > - Whenever a stack is allocated we assign READ_WRITE  memory attributes
> to the memory region, the stack attribute structure is appended to a chain
> for tracking
> > - On each context switch, the executing stack is marked as 'not-current'
> and we unset its memory attributes. The heir stack is marked as 'current'
> > - On context restore we set the memory attributes of the heir stack and
> iterate thorugh the chain to check for any other 'current' stack and unset
> its memory
> >   attribute (This requires some refinement, so that we don't have to
> iterate over the chain).
>
> Commit formatting:
> https://docs.rtems.org/branches/master/eng/vc-users.html#creating-a-patch
> points to: https://devel.rtems.org/wiki/Developer/Git#GitCommits
> -- that should probably get merged to the docs.
>
> It may not say in our docs, but wrap your commit messages to 80 chars.
> The first line looks best at about 60 characters when it gets used as
> a 'summary'. The way you've written a set of bullets is more like
> paragraphs. You might just aim to write paragraphs. Bullets are nice
> when you want to format a list of related items. In that case, you
> should provide a list heading for some structure/organization.
>
>
> > ---
> >  .../include/bsp/arm-cp15-set-ttb-entries.h|   0
> >  bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c   |  79 
> >  bsps/shared/start/stackalloc.c|  16 ++
> >  c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am  |   5 +-
> >  cpukit/Makefile.am|   1 +
> >  cpukit/headers.am |   2 +
> >  cpukit/include/rtems/score/memorymanagement.h |  89 +
> >  cpukit/include/rtems/score/stackprotection.h  | 149 ++
> >  cpukit/score/cpu/arm/cpu.c|   4 +
> >  cpukit/score/cpu/arm/cpu_asm.S|  43 +++-
> >  .../score/cpu/arm/include/rtems/score/cpu.h   |  18 ++
> >  cpukit/score/src/stackprotection.c| 185 ++
> >  12 files changed, 589 insertions(+), 2 deletions(-)
> >  create mode 100644 bsps/arm/include/bsp/arm-cp15-set-ttb-entries.h
> >  create mode 100644 bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c
> >  create mode 100644 cpukit/include/rtems/score/memorymanagement.h
> >  create mode 100644 cpukit/include/rtems/score/stackprotection.h
> >  create mode 100644 cpukit/score/src/stackprotection.c
> >
> > diff --git a/bsps/arm/include/bsp/arm-cp15-set-ttb-entries.h
> b/bsps/arm/include/bsp/arm-cp15-set-ttb-entries.h
> > new file mode 100644
> > index 00..e69de29bb2
> > diff --git a/bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c
> b/bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c
> > new file mode 100644
> > index 00..0c82f113a9
> > --- /dev/null
> > +++ b/bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c
> > @@ -0,0 +1,79 @@
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
>
> This could use a comment why it is necessary. And also a note about
> converting to a configuration option
> > +#ifdef USE_THREAD_STACK_PROTECTION
> > +  #define ARM_MMU_USE_SMALL_PAGES
> > +#endif
> > +
>
> Although it is not strictly required to have doxygen in the BSPs, I
> would like to see some function documentation of this new interface.
> > +void Memorymanagement_Set_entries(uintptr_t begin, size_t size,
> Memorymanagement_flags flags)
>
> I don't like the namespace choice. Did you discuss this with anyone?
>
> The naming rules are in
> https://docs.rtems.org/branches/master/eng/coding-naming.html
>
> I guess we haven't codified the BSP interface rules. You might inquire
> in a separate thread for some discussion. From what I recall, we have
> bsp_* for some generic kind of functions that should be implemented by
> bsp. So if this is meant to be a BSP implemented interface, you might
> like "bsp_memory_management" or some such.


> Memory manageme

[PATCH v2] Thread-stack isolation

[Utkarsh Rai]

The following is the rectified patch and does not break the build.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2] Strict thread-stack isolation

[Utkarsh Rai]

. 
+  */
+  page_table_base = (uintptr_t)0x1000;   
+
+  /**
+   * The current way to get protected stack is to assign memory attributes
+   *  to the allocated memory.
+  */
+  _Stackprotection_Allocate_attr( (uintptr_t)stack, size, page_table_base );
+
+#endif
   return stack;
 }
 
diff --git a/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am 
b/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
index cfd59475c2..490f99792e 100644
--- a/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
+++ b/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
@@ -74,6 +74,9 @@ librtemsbsp_a_SOURCES += 
../../../../../../bsps/arm/xilinx-zynq/i2c/cadence-i2c.
 # Cache
 librtemsbsp_a_SOURCES += 
../../../../../../bsps/arm/shared/cache/cache-l2c-310.c
 
+#MMU
+librtemsbsp_a_SOURCES += 
../../../../../../bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c
+
 # Start hooks
 librtemsbsp_a_SOURCES += 
../../../../../../bsps/arm/xilinx-zynq/start/bspstarthooks.c
 librtemsbsp_a_SOURCES += 
../../../../../../bsps/arm/xilinx-zynq/start/bspstartmmu.c
@@ -85,4 +88,4 @@ librtemsbsp_a_SOURCES += 
../../../../../../bsps/arm/xilinx-zynq/start/bspstartmm
 
 include $(srcdir)/../../../../../../bsps/shared/irq-sources.am
 include $(srcdir)/../../../../../../bsps/shared/shared-sources.am
-include $(srcdir)/../../../../../../bsps/arm/xilinx-zynq/headers.am
+include $(srcdir)/../../../../../../bsps/arm/xilinx-zynq/headers.am
\ No newline at end of file
diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index 51f38c84c7..83f9bfb3ef 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -929,6 +929,7 @@ librtemscpu_a_SOURCES += score/src/schedulercbsgetserverid.c
 librtemscpu_a_SOURCES += score/src/schedulercbssetparameters.c
 librtemscpu_a_SOURCES += score/src/schedulercbsreleasejob.c
 librtemscpu_a_SOURCES += score/src/schedulercbsunblock.c
+librtemscpu_a_SOURCES += score/src/stackprotection.c
 librtemscpu_a_SOURCES += score/src/stackallocator.c
 librtemscpu_a_SOURCES += score/src/pheapallocate.c
 librtemscpu_a_SOURCES += score/src/pheapextend.c
diff --git a/cpukit/headers.am b/cpukit/headers.am
index fcf679f09d..2f16c71d9c 100644
--- a/cpukit/headers.am
+++ b/cpukit/headers.am
@@ -352,6 +352,7 @@ include_rtems_score_HEADERS += include/rtems/score/isr.h
 include_rtems_score_HEADERS += include/rtems/score/isrlevel.h
 include_rtems_score_HEADERS += include/rtems/score/isrlock.h
 include_rtems_score_HEADERS += include/rtems/score/memory.h
+include_rtems_score_HEADERS += include/rtems/score/memorymanagement.h
 include_rtems_score_HEADERS += include/rtems/score/mpci.h
 include_rtems_score_HEADERS += include/rtems/score/mpciimpl.h
 include_rtems_score_HEADERS += include/rtems/score/mppkt.h
@@ -405,6 +406,7 @@ include_rtems_score_HEADERS += 
include/rtems/score/smplockstats.h
 include_rtems_score_HEADERS += include/rtems/score/smplockticket.h
 include_rtems_score_HEADERS += include/rtems/score/stack.h
 include_rtems_score_HEADERS += include/rtems/score/stackimpl.h
+include_rtems_score_HEADERS += include/rtems/score/stackprotection.h
 include_rtems_score_HEADERS += include/rtems/score/states.h
 include_rtems_score_HEADERS += include/rtems/score/statesimpl.h
 include_rtems_score_HEADERS += include/rtems/score/status.h
diff --git a/cpukit/include/rtems/score/memorymanagement.h 
b/cpukit/include/rtems/score/memorymanagement.h
new file mode 100644
index 00..2a5490c680
--- /dev/null
+++ b/cpukit/include/rtems/score/memorymanagement.h
@@ -0,0 +1,89 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSScoreMemorymanagement
+ *
+ * @brief This file provodes APIs for high-level memory management
+ * 
+ */
+
+/*
+ * Copyright (C) 2020 Utkarsh Rai
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF S

Re: [PATCH v2] Strict thread-stack isolation

[Utkarsh Rai]

Kindly ignore this patch. It breaks the build.

On Thu, Jul 16, 2020 at 4:54 PM Utkarsh Rai  wrote:

> - This is the complete set of changes for strict isolation of thread
> stacks.
> - There needs to be a confiuration operation,(#if
> defined(USE_THREAD_STACK_PROTECTION) for simple configuration can be used)
> - The stack attributes are allocated through malloc, this needs to be done
> through score unlimited objects.
>
> Mechanism for thread-stack isolation
> - Whenever a stack is allocated we assign READ_WRITE  memory attributes to
> the memory region, the stack attribute structure is appended to a chain for
> tracking
> - On each context switch, the executing stack is marked as 'not-current'
> and we unset its memory attributes. The heir stack is marked as 'current'
> - On context restore we set the memory attributes of the heir stack and
> iterate thorugh the chain to check for any other 'current' stack and unset
> its memory
>   attribute (This requires some refinement, so that we don't have to
> iterate over the chain).
> ---
>  .../include/bsp/arm-cp15-set-ttb-entries.h|   0
>  bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c   |  79 
>  bsps/shared/start/stackalloc.c|  16 ++
>  c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am  |   5 +-
>  cpukit/Makefile.am|   1 +
>  cpukit/headers.am |   2 +
>  cpukit/include/rtems/score/memorymanagement.h |  89 +
>  cpukit/include/rtems/score/stackprotection.h  | 149 ++
>  cpukit/score/cpu/arm/cpu.c|   4 +
>  cpukit/score/cpu/arm/cpu_asm.S|  45 -
>  .../score/cpu/arm/include/rtems/score/cpu.h   |  18 ++
>  cpukit/score/src/stackprotection.c| 188 ++
>  12 files changed, 593 insertions(+), 3 deletions(-)
>  create mode 100644 bsps/arm/include/bsp/arm-cp15-set-ttb-entries.h
>  create mode 100644 bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c
>  create mode 100644 cpukit/include/rtems/score/memorymanagement.h
>  create mode 100644 cpukit/include/rtems/score/stackprotection.h
>  create mode 100644 cpukit/score/src/stackprotection.c
>
> diff --git a/bsps/arm/include/bsp/arm-cp15-set-ttb-entries.h
> b/bsps/arm/include/bsp/arm-cp15-set-ttb-entries.h
> new file mode 100644
> index 00..e69de29bb2
> diff --git a/bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c
> b/bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c
> new file mode 100644
> index 00..0c82f113a9
> --- /dev/null
> +++ b/bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c
> @@ -0,0 +1,79 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#ifdef USE_THREAD_STACK_PROTECTION
> +  #define ARM_MMU_USE_SMALL_PAGES
> +#endif
> +
> +void Memorymanagement_Set_entries(uintptr_t begin, size_t size,
> Memorymanagement_flags flags)
> +{
> +
> +uintptr_t end;
> +rtems_interrupt_level irq_level;
> +uint32_t access_flags;
> +
> +end = begin + size;
> +access_flags = Memorymanagement_Translate_flags(flags);
> +
> +/**
> + *  The ARM reference manual instructs to disable all the interrupts
> before
> + * setting up page table entries.
> +*/
> +rtems_interrupt_disable(irq_level);
> +arm_cp15_set_translation_table_entries(begin, end, access_flags);
> +rtems_interrupt_enable(irq_level);
> +}
> +
> +void Memorymanagement_Unset_entries(uintptr_t begin, size_t size)
> +{
> +  uint32_t access_flags;
> +  uintptr_t end;
> +  rtems_interrupt_level irq_level;
> +
> +  end = begin + size;
> +  access_flags = Memorymanagement_Translate_flags(NO_ACCESS);
> +
> +   /**
> + *  The ARM reference manual instructs to disable all the interrupts
> before
> + * setting up page table entries.
> +*/
> +  rtems_interrupt_disable(irq_level);
> +  arm_cp15_set_translation_table_entries(begin, end, access_flags);
> +  rtems_interrupt_enable(irq_level);
> +}
> +
> +
> +uint32_t Memorymanagement_Translate_flags(Memorymanagement_flags
> attr_flags)
> +{
> +  uint32_t flags;
> +  switch (attr_flags)
> +  {
> +  case READ_WRITE:
> + flags = ARMV7_MMU_READ_WRITE;
> +  break;
> +
> +  case READ_WRITE_CACHED:
> +flags = ARMV7_MMU_DATA_READ_WRITE_CACHED;
> +  break;
> +
> +  case READ_ONLY:
> +flags = ARMV7_MMU_READ_ONLY;
> +  break;
> +
> +  case READ_ONLY_CACHED:
> +flags = ARMV7_MMU_READ_ONLY_CACHED;
> +  break;
> +
> +  case NO_ACCESS:
> +flags = 0;
> +  break;
> +
> +  default:
> + return 0;
> +  break;
> +  }
> +
> +  return flags;
> +}
> \ No newline at end of file
> diff --git a/bsps/shared/start/stackalloc

[PATCH v2] Strict thread-stack isolation

[Utkarsh Rai]

. 
+  */
+  page_table_base = (uintptr_t)0x1000;   
+
+  /**
+   * The current way to get protected stack is to assign memory attributes
+   *  to the allocated memory.
+  */
+  _Stackprotection_Allocate_attr( (uintptr_t)stack, size, page_table_base );
+
+#endif
   return stack;
 }
 
diff --git a/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am 
b/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
index cfd59475c2..490f99792e 100644
--- a/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
+++ b/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
@@ -74,6 +74,9 @@ librtemsbsp_a_SOURCES += 
../../../../../../bsps/arm/xilinx-zynq/i2c/cadence-i2c.
 # Cache
 librtemsbsp_a_SOURCES += 
../../../../../../bsps/arm/shared/cache/cache-l2c-310.c
 
+#MMU
+librtemsbsp_a_SOURCES += 
../../../../../../bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c
+
 # Start hooks
 librtemsbsp_a_SOURCES += 
../../../../../../bsps/arm/xilinx-zynq/start/bspstarthooks.c
 librtemsbsp_a_SOURCES += 
../../../../../../bsps/arm/xilinx-zynq/start/bspstartmmu.c
@@ -85,4 +88,4 @@ librtemsbsp_a_SOURCES += 
../../../../../../bsps/arm/xilinx-zynq/start/bspstartmm
 
 include $(srcdir)/../../../../../../bsps/shared/irq-sources.am
 include $(srcdir)/../../../../../../bsps/shared/shared-sources.am
-include $(srcdir)/../../../../../../bsps/arm/xilinx-zynq/headers.am
+include $(srcdir)/../../../../../../bsps/arm/xilinx-zynq/headers.am
\ No newline at end of file
diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index 51f38c84c7..83f9bfb3ef 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -929,6 +929,7 @@ librtemscpu_a_SOURCES += score/src/schedulercbsgetserverid.c
 librtemscpu_a_SOURCES += score/src/schedulercbssetparameters.c
 librtemscpu_a_SOURCES += score/src/schedulercbsreleasejob.c
 librtemscpu_a_SOURCES += score/src/schedulercbsunblock.c
+librtemscpu_a_SOURCES += score/src/stackprotection.c
 librtemscpu_a_SOURCES += score/src/stackallocator.c
 librtemscpu_a_SOURCES += score/src/pheapallocate.c
 librtemscpu_a_SOURCES += score/src/pheapextend.c
diff --git a/cpukit/headers.am b/cpukit/headers.am
index fcf679f09d..2f16c71d9c 100644
--- a/cpukit/headers.am
+++ b/cpukit/headers.am
@@ -352,6 +352,7 @@ include_rtems_score_HEADERS += include/rtems/score/isr.h
 include_rtems_score_HEADERS += include/rtems/score/isrlevel.h
 include_rtems_score_HEADERS += include/rtems/score/isrlock.h
 include_rtems_score_HEADERS += include/rtems/score/memory.h
+include_rtems_score_HEADERS += include/rtems/score/memorymanagement.h
 include_rtems_score_HEADERS += include/rtems/score/mpci.h
 include_rtems_score_HEADERS += include/rtems/score/mpciimpl.h
 include_rtems_score_HEADERS += include/rtems/score/mppkt.h
@@ -405,6 +406,7 @@ include_rtems_score_HEADERS += 
include/rtems/score/smplockstats.h
 include_rtems_score_HEADERS += include/rtems/score/smplockticket.h
 include_rtems_score_HEADERS += include/rtems/score/stack.h
 include_rtems_score_HEADERS += include/rtems/score/stackimpl.h
+include_rtems_score_HEADERS += include/rtems/score/stackprotection.h
 include_rtems_score_HEADERS += include/rtems/score/states.h
 include_rtems_score_HEADERS += include/rtems/score/statesimpl.h
 include_rtems_score_HEADERS += include/rtems/score/status.h
diff --git a/cpukit/include/rtems/score/memorymanagement.h 
b/cpukit/include/rtems/score/memorymanagement.h
new file mode 100644
index 00..2a5490c680
--- /dev/null
+++ b/cpukit/include/rtems/score/memorymanagement.h
@@ -0,0 +1,89 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSScoreMemorymanagement
+ *
+ * @brief This file provodes APIs for high-level memory management
+ * 
+ */
+
+/*
+ * Copyright (C) 2020 Utkarsh Rai
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF S

Re: [PATCH] Strict thread-stack isolation

[Utkarsh Rai]

On Tue, Jul 14, 2020 at 7:36 PM Gedare Bloom  wrote:

> I won't comment on the namespace and coding conventions, other than to
> say you should focus on doing them correctly as you code, rather than
> going back and fixing them later. More below.
>
> On Mon, Jul 13, 2020 at 10:34 AM Utkarsh Rai 
> wrote:
> >
> > - This is the complete set of changes for strict isolation of thread
> stacks.
> > - There needs to be a confiuration operation,(#if
> defined(USE_THREAD_STACK_PROTECTION) for simple configuration can be used)
> > - The stack attributes are allocated through malloc, this needs to be
> done through score unlimited objects.
> > ---
> >  bsps/arm/headers.am   |   1 +
> >  .../include/bsp/arm-cp15-set-ttb-entries.h|   7 +
> >  .../shared/cp15/arm-cp15-set-ttb-entries.c|   3 +
> >  bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c   |  72 +
> >  bsps/shared/start/stackalloc.c|  20 ++-
> >  c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am  |   5 +-
> >  cpukit/Makefile.am|   1 +
> >  cpukit/headers.am |   2 +
> >  cpukit/include/rtems/score/memorymanagement.h |  22 +++
> >  cpukit/include/rtems/score/stackmanagement.h  |  49 ++
> >  cpukit/score/cpu/arm/cpu.c|   3 +
> >  cpukit/score/cpu/arm/cpu_asm.S|  22 ++-
> >  .../score/cpu/arm/include/rtems/score/cpu.h   |  20 +++
> >  cpukit/score/src/stackmanagement.c| 143 ++
> >  14 files changed, 365 insertions(+), 5 deletions(-)
> >  create mode 100644 bsps/arm/include/bsp/arm-cp15-set-ttb-entries.h
> >  create mode 100644 bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c
> >  create mode 100644 cpukit/include/rtems/score/memorymanagement.h
> >  create mode 100644 cpukit/include/rtems/score/stackmanagement.h
> >  create mode 100644 cpukit/score/src/stackmanagement.c
> >
> > diff --git a/bsps/arm/headers.am b/bsps/arm/headers.am
> > index 3d2b09effa..b1e86f3385 100644
> > --- a/bsps/arm/headers.am
> > +++ b/bsps/arm/headers.am
> > @@ -15,6 +15,7 @@ include_bsp_HEADERS +=
> ../../../../../bsps/arm/include/bsp/arm-a9mpcore-clock.h
> >  include_bsp_HEADERS +=
> ../../../../../bsps/arm/include/bsp/arm-a9mpcore-irq.h
> >  include_bsp_HEADERS +=
> ../../../../../bsps/arm/include/bsp/arm-a9mpcore-regs.h
> >  include_bsp_HEADERS +=
> ../../../../../bsps/arm/include/bsp/arm-a9mpcore-start.h
> > +include_bsp_HEADERS +=
> ../../../../../bsps/arm/include/bsp/arm-cp15-set-ttb-entries.h
> >  include_bsp_HEADERS +=
> ../../../../../bsps/arm/include/bsp/arm-cp15-start.h
> >  include_bsp_HEADERS += ../../../../../bsps/arm/include/bsp/arm-errata.h
> >  include_bsp_HEADERS += ../../../../../bsps/arm/include/bsp/arm-gic-irq.h
> > diff --git a/bsps/arm/include/bsp/arm-cp15-set-ttb-entries.h
> b/bsps/arm/include/bsp/arm-cp15-set-ttb-entries.h
> > new file mode 100644
> > index 00..39170927da
> > --- /dev/null
> > +++ b/bsps/arm/include/bsp/arm-cp15-set-ttb-entries.h
> > @@ -0,0 +1,7 @@
> > +#include
> > +
> > +uint32_t arm_cp15_set_translation_table_entries(
> > +  const void *begin,
> > +  const void *end,
> > +  uint32_t section_flags
> > +);
> > \ No newline at end of file
> > diff --git a/bsps/arm/shared/cp15/arm-cp15-set-ttb-entries.c
> b/bsps/arm/shared/cp15/arm-cp15-set-ttb-entries.c
> > index 507277dca1..f5d0494167 100644
> > --- a/bsps/arm/shared/cp15/arm-cp15-set-ttb-entries.c
> > +++ b/bsps/arm/shared/cp15/arm-cp15-set-ttb-entries.c
> > @@ -14,6 +14,7 @@
> >
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >
> >  /*
> > @@ -30,6 +31,8 @@
> >   * ARM DDI 0406C.b (ID072512)
> >   */
> >
> > +#define ARM_MMU_USE_SMALL_PAGES
> > +
> >  static uint32_t set_translation_table_entries(
> >const void *begin,
> >const void *end,
> > diff --git a/bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c
> b/bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c
> > new file mode 100644
> > index 00..978e35b86c
> > --- /dev/null
> > +++ b/bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c
> > @@ -0,0 +1,72 @@
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#ifdef USE_THREAD_STACK_PROTECTION
> > +  #define ARM_MMU_USE_SMALL_PAGES
> > +#endif
> > +
> > +void memory_entries_set(uintptr_t begin, size_t size, memory_flags
> flags)
> > +{
> > +
> > +uintptr_t end;
> &g

Re: [PATCH] Strict thread-stack isolation

[Utkarsh Rai]

On Tue, Jul 14, 2020 at 1:13 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Utkarsh,
>
> if you look a the stuff you added to the score and compare it with
> something existing in the score, do you notice differences in the naming
> conventions and the code format? Have you looked at
>
> https://docs.rtems.org/branches/master/eng/coding.html
>
> ?
>

Yes, sorry, I realize I need to do a better job with the coding standard
and maintaining namespace consistency. I will rectify this.


> On 13/07/2020 18:33, Utkarsh Rai wrote:
> > - This is the complete set of changes for strict isolation of thread
> stacks.
> > - There needs to be a confiuration operation,(#if
> defined(USE_THREAD_STACK_PROTECTION) for simple configuration can be used)
> > - The stack attributes are allocated through malloc, this needs to be
> done through score unlimited objects.
> > ---
> >   bsps/arm/headers.am   |   1 +
> >   .../include/bsp/arm-cp15-set-ttb-entries.h|   7 +
> >   .../shared/cp15/arm-cp15-set-ttb-entries.c|   3 +
> >   bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c   |  72 +
> >   bsps/shared/start/stackalloc.c|  20 ++-
> >   c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am  |   5 +-
> >   cpukit/Makefile.am|   1 +
> >   cpukit/headers.am |   2 +
> >   cpukit/include/rtems/score/memorymanagement.h |  22 +++
> >   cpukit/include/rtems/score/stackmanagement.h  |  49 ++
> >   cpukit/score/cpu/arm/cpu.c|   3 +
> >   cpukit/score/cpu/arm/cpu_asm.S|  22 ++-
> >   .../score/cpu/arm/include/rtems/score/cpu.h   |  20 +++
> >   cpukit/score/src/stackmanagement.c| 143 ++
> >   14 files changed, 365 insertions(+), 5 deletions(-)
> >   create mode 100644 bsps/arm/include/bsp/arm-cp15-set-ttb-entries.h
> >   create mode 100644 bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c
> >   create mode 100644 cpukit/include/rtems/score/memorymanagement.h
> >   create mode 100644 cpukit/include/rtems/score/stackmanagement.h
> >   create mode 100644 cpukit/score/src/stackmanagement.c
> >
> > diff --git a/bsps/arm/headers.am b/bsps/arm/headers.am
> > index 3d2b09effa..b1e86f3385 100644
> > --- a/bsps/arm/headers.am
> > +++ b/bsps/arm/headers.am
> > @@ -15,6 +15,7 @@ include_bsp_HEADERS +=
> ../../../../../bsps/arm/include/bsp/arm-a9mpcore-clock.h
> >   include_bsp_HEADERS +=
> ../../../../../bsps/arm/include/bsp/arm-a9mpcore-irq.h
> >   include_bsp_HEADERS +=
> ../../../../../bsps/arm/include/bsp/arm-a9mpcore-regs.h
> >   include_bsp_HEADERS +=
> ../../../../../bsps/arm/include/bsp/arm-a9mpcore-start.h
> > +include_bsp_HEADERS +=
> ../../../../../bsps/arm/include/bsp/arm-cp15-set-ttb-entries.h
> >   include_bsp_HEADERS +=
> ../../../../../bsps/arm/include/bsp/arm-cp15-start.h
> >   include_bsp_HEADERS += ../../../../../bsps/arm/include/bsp/arm-errata.h
> >   include_bsp_HEADERS +=
> ../../../../../bsps/arm/include/bsp/arm-gic-irq.h
> > diff --git a/bsps/arm/include/bsp/arm-cp15-set-ttb-entries.h
> b/bsps/arm/include/bsp/arm-cp15-set-ttb-entries.h
> > new file mode 100644
> > index 00..39170927da
> > --- /dev/null
> > +++ b/bsps/arm/include/bsp/arm-cp15-set-ttb-entries.h
> > @@ -0,0 +1,7 @@
> > +#include
> > +
> > +uint32_t arm_cp15_set_translation_table_entries(
> > +  const void *begin,
> > +  const void *end,
> > +  uint32_t section_flags
> > +);
> > \ No newline at end of file
> Why did you add this header file?
>

It was not meant to be included in the patch, this has crept in while I was
squashing the commits.


> > diff --git a/bsps/arm/shared/cp15/arm-cp15-set-ttb-entries.c
> b/bsps/arm/shared/cp15/arm-cp15-set-ttb-entries.c
> > index 507277dca1..f5d0494167 100644
> > --- a/bsps/arm/shared/cp15/arm-cp15-set-ttb-entries.c
> > +++ b/bsps/arm/shared/cp15/arm-cp15-set-ttb-entries.c
> > @@ -14,6 +14,7 @@
> >
> >   #include 
> >   #include 
> > +#include 
> >   #include 
> >
> >   /*
> > @@ -30,6 +31,8 @@
> >* ARM DDI 0406C.b (ID072512)
> >*/
> >
> > +#define ARM_MMU_USE_SMALL_PAGES
> > +
>
> This is the wrong place to define this define. This is supposed to be a
> BSP option.
>
> >   static uint32_t set_translation_table_entries(
> > const void *begin,
> > const void *end,
> > diff --git a/bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c
> b/bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c
> > new fi

[PATCH] Strict thread-stack isolation

[Utkarsh Rai]

- This is the complete set of changes for strict isolation of thread stacks.
- There needs to be a confiuration operation,(#if 
defined(USE_THREAD_STACK_PROTECTION) for simple configuration can be used)
- The stack attributes are allocated through malloc, this needs to be done 
through score unlimited objects.
---
 bsps/arm/headers.am   |   1 +
 .../include/bsp/arm-cp15-set-ttb-entries.h|   7 +
 .../shared/cp15/arm-cp15-set-ttb-entries.c|   3 +
 bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c   |  72 +
 bsps/shared/start/stackalloc.c|  20 ++-
 c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am  |   5 +-
 cpukit/Makefile.am|   1 +
 cpukit/headers.am |   2 +
 cpukit/include/rtems/score/memorymanagement.h |  22 +++
 cpukit/include/rtems/score/stackmanagement.h  |  49 ++
 cpukit/score/cpu/arm/cpu.c|   3 +
 cpukit/score/cpu/arm/cpu_asm.S|  22 ++-
 .../score/cpu/arm/include/rtems/score/cpu.h   |  20 +++
 cpukit/score/src/stackmanagement.c| 143 ++
 14 files changed, 365 insertions(+), 5 deletions(-)
 create mode 100644 bsps/arm/include/bsp/arm-cp15-set-ttb-entries.h
 create mode 100644 bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c
 create mode 100644 cpukit/include/rtems/score/memorymanagement.h
 create mode 100644 cpukit/include/rtems/score/stackmanagement.h
 create mode 100644 cpukit/score/src/stackmanagement.c

diff --git a/bsps/arm/headers.am b/bsps/arm/headers.am
index 3d2b09effa..b1e86f3385 100644
--- a/bsps/arm/headers.am
+++ b/bsps/arm/headers.am
@@ -15,6 +15,7 @@ include_bsp_HEADERS += 
../../../../../bsps/arm/include/bsp/arm-a9mpcore-clock.h
 include_bsp_HEADERS += ../../../../../bsps/arm/include/bsp/arm-a9mpcore-irq.h
 include_bsp_HEADERS += ../../../../../bsps/arm/include/bsp/arm-a9mpcore-regs.h
 include_bsp_HEADERS += ../../../../../bsps/arm/include/bsp/arm-a9mpcore-start.h
+include_bsp_HEADERS += 
../../../../../bsps/arm/include/bsp/arm-cp15-set-ttb-entries.h
 include_bsp_HEADERS += ../../../../../bsps/arm/include/bsp/arm-cp15-start.h
 include_bsp_HEADERS += ../../../../../bsps/arm/include/bsp/arm-errata.h
 include_bsp_HEADERS += ../../../../../bsps/arm/include/bsp/arm-gic-irq.h
diff --git a/bsps/arm/include/bsp/arm-cp15-set-ttb-entries.h 
b/bsps/arm/include/bsp/arm-cp15-set-ttb-entries.h
new file mode 100644
index 00..39170927da
--- /dev/null
+++ b/bsps/arm/include/bsp/arm-cp15-set-ttb-entries.h
@@ -0,0 +1,7 @@
+#include
+
+uint32_t arm_cp15_set_translation_table_entries(
+  const void *begin,
+  const void *end,
+  uint32_t section_flags
+);
\ No newline at end of file
diff --git a/bsps/arm/shared/cp15/arm-cp15-set-ttb-entries.c 
b/bsps/arm/shared/cp15/arm-cp15-set-ttb-entries.c
index 507277dca1..f5d0494167 100644
--- a/bsps/arm/shared/cp15/arm-cp15-set-ttb-entries.c
+++ b/bsps/arm/shared/cp15/arm-cp15-set-ttb-entries.c
@@ -14,6 +14,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 /*
@@ -30,6 +31,8 @@
  * ARM DDI 0406C.b (ID072512)
  */
 
+#define ARM_MMU_USE_SMALL_PAGES
+
 static uint32_t set_translation_table_entries(
   const void *begin,
   const void *end,
diff --git a/bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c 
b/bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c
new file mode 100644
index 00..978e35b86c
--- /dev/null
+++ b/bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c
@@ -0,0 +1,72 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifdef USE_THREAD_STACK_PROTECTION
+  #define ARM_MMU_USE_SMALL_PAGES
+#endif
+
+void memory_entries_set(uintptr_t begin, size_t size, memory_flags flags)
+{
+   
+uintptr_t end;
+rtems_interrupt_level irq_level;
+uint32_t access_flags;
+
+end = begin + size;
+access_flags = memory_translate_flags(flags);
+
+rtems_interrupt_local_disable(irq_level);
+arm_cp15_set_translation_table_entries(begin, end, access_flags); 
+rtems_interrupt_local_enable(irq_level);
+}
+
+void memory_entries_unset(uintptr_t begin, size_t size)
+{
+  uint32_t access_flags;
+  uintptr_t end;
+  rtems_interrupt_level irq_level;
+
+  end = begin + size;
+  access_flags = memory_translate_flags(NO_ACCESS);
+
+  rtems_interrupt_local_disable(irq_level);
+  arm_cp15_set_translation_table_entries(begin, end, access_flags); 
+  rtems_interrupt_local_enable(irq_level);
+}
+
+
+uint32_t memory_translate_flags(memory_flags attr_flags)
+{
+  uint32_t flags;
+  switch (attr_flags)
+  {
+  case READ_WRITE: 
+ flags = ARMV7_MMU_READ_WRITE;
+  break;
+
+  case READ_WRITE_CACHED:
+flags = ARMV7_MMU_DATA_READ_WRITE_CACHED;
+  break;
+
+  case READ_ONLY:
+flags = ARMV7_MMU_READ_ONLY;
+  break;
+
+  case READ_ONLY_CACHED:
+flags = ARMV7_MMU_READ_ONLY_CACHED;
+  break;
+
+  case NO_ACCESS:
+flags = 0;
+  break;
+  
+  default:
+ return -1;
+  break;
+  }
+
+  return flags;
+}
\ No newline at end of file
diff --git a/bsps/shared/start/stackalloc.c 

Re: Converting stack address to shared-memory object name

[Utkarsh Rai]

On Thu, Jul 9, 2020 at 8:57 PM Gedare Bloom  wrote:

> On Thu, Jul 9, 2020 at 9:24 AM Gedare Bloom  wrote:
> >
> > On Wed, Jul 8, 2020 at 10:08 PM Utkarsh Rai 
> wrote:
> > >
> > >
> > >
> > >
> > > On Wed, Jul 8, 2020 at 6:56 PM Gedare Bloom  wrote:
> > >>
> > >> On Wed, Jul 8, 2020 at 6:53 AM Sebastian Huber
> > >>  wrote:
> > >> >
> > >> > On 08/07/2020 14:43, Utkarsh Rai wrote:
> > >> >
> > >> > > Hello,
> > >> > > For my GSoC project, I have to provide high-level APIs for sharing
> > >> > > isolated stacks.
> > >> > > The POSIX compliant high-level way of sharing stacks can be to
> create
> > >> > > a shared memory object of the stack to be shared through shm_open
> and
> > >> > > then mmap that to the address space of the current stack. My
> doubt is,
> > >> > > shm_open() takes the path-name of the shared memory object. Since
> this
> > >> > > is a high-level API, how does the user 'convert' the stack
> address to
> > >> > > a shared memory object name?
> > >> > Do we need any POSIX compatibility for this? What would you do in a
> > >> > POSIX environment? You first get some memory, then hand it over to
> > >> > shm_open() to get a file descriptor, then use the file descriptor in
> > >> > mmap(), then use this for pthread_attr_setstack() and whatever?
> > >>
> > >> Yes, but the way to name objects is not set by posix.
> > >>
> > >> We need to provide our own way of translating an address into a name.
> > >>
> > >> > >
> > >> > > Dr.Gedare mentioned that one way to deal with naming would be
> > >> > > something like Mr.Sebastian has been doing with specifications.
> From
> > >> > > what I could gather, it is a hierarchical way of representing
> > >> > > objects(Though, I am not very sure if  I understand this
> accurately).
> > >> > > How can something like this be implemented for naming
> stack-addresses?
> > >> > I am not sure if the specification of RTEMS is helpful in this
> context.
> > >>
> > >> I should have provided a little bit more guidance. I was thinking out
> > >> loud in yesterday's IRC meeting. My thought was more along the lines
> > >> of looking at how UIDs/naming should be done, and that specs had to
> > >> solve a naming problem. However the static nature of specs is not a
> > >> great fit to this problem.
> > >>
> > >> Actually, what is a good model would be something like /proc or
> > >> Linux's sysfs. An IMFS filesystem that exports task information could
> > >> be used to name memory regions. (It could eventually supplant
> > >> task-based statistics reporting too.)
> > >>
> > >> Another idea I had though, which seems to have been lost in the
> > >> shuffle, is to look at how the object names work in RTEMS and see if
> > >> we can add some fixed relationships, e.g., task_name # stack.
> > >>
> > >> I think we should start by just treating the entire task stack as a
> > >> single named object; either it is all shared, or none of it is shared.
> > >> This will be easier to implement and also more widely supported by
> > >> simpler MPU/MMU hardware. Later on, we can consider extending the
> > >> namespace with 'offsets' /taskfs/IDLE/stack/0A28
> > >> could be a location at byte A28 offset from the start of the stack of
> > >> the IDLE task.
> > >>
> > >
> > > I have a few questions -
> > >
> > > > Users would get the stack address of the stack they want to share
> through pthread_attr_getstack(). Now, when they get the address they want
> to share, they would pass the appropriate name of this memory-region. What
> we have to provide is a mechanism to 'convert' this address to an
> appropriate name. Is this the accepted way or the other way round, i.e. the
> user passes a name as per a specified convention, and that name is
> 'converted' to a specific address?
> > >
> > We may want both to work. You definitely want to have the
> > address->name working though, at the very least with the base address
> > returned by pthread_attr_getstack, but you might also want to be able
> > to map any address in a task's stack to the stack's &qu

Re: Converting stack address to shared-memory object name

[Utkarsh Rai]

On Wed, Jul 8, 2020 at 6:56 PM Gedare Bloom  wrote:

> On Wed, Jul 8, 2020 at 6:53 AM Sebastian Huber
>  wrote:
> >
> > On 08/07/2020 14:43, Utkarsh Rai wrote:
> >
> > > Hello,
> > > For my GSoC project, I have to provide high-level APIs for sharing
> > > isolated stacks.
> > > The POSIX compliant high-level way of sharing stacks can be to create
> > > a shared memory object of the stack to be shared through shm_open and
> > > then mmap that to the address space of the current stack. My doubt is,
> > > shm_open() takes the path-name of the shared memory object. Since this
> > > is a high-level API, how does the user 'convert' the stack address to
> > > a shared memory object name?
> > Do we need any POSIX compatibility for this? What would you do in a
> > POSIX environment? You first get some memory, then hand it over to
> > shm_open() to get a file descriptor, then use the file descriptor in
> > mmap(), then use this for pthread_attr_setstack() and whatever?
>
> Yes, but the way to name objects is not set by posix.
>
> We need to provide our own way of translating an address into a name.
>
> > >
> > > Dr.Gedare mentioned that one way to deal with naming would be
> > > something like Mr.Sebastian has been doing with specifications. From
> > > what I could gather, it is a hierarchical way of representing
> > > objects(Though, I am not very sure if  I understand this accurately).
> > > How can something like this be implemented for naming stack-addresses?
> > I am not sure if the specification of RTEMS is helpful in this context.
>
> I should have provided a little bit more guidance. I was thinking out
> loud in yesterday's IRC meeting. My thought was more along the lines
> of looking at how UIDs/naming should be done, and that specs had to
> solve a naming problem. However the static nature of specs is not a
> great fit to this problem.
>
> Actually, what is a good model would be something like /proc or
> Linux's sysfs. An IMFS filesystem that exports task information could
> be used to name memory regions. (It could eventually supplant
> task-based statistics reporting too.)
>
> Another idea I had though, which seems to have been lost in the
> shuffle, is to look at how the object names work in RTEMS and see if
> we can add some fixed relationships, e.g., task_name # stack.
>
> I think we should start by just treating the entire task stack as a
> single named object; either it is all shared, or none of it is shared.
> This will be easier to implement and also more widely supported by
> simpler MPU/MMU hardware. Later on, we can consider extending the
> namespace with 'offsets' /taskfs/IDLE/stack/0A28
> could be a location at byte A28 offset from the start of the stack of
> the IDLE task.
>
>
I have a few questions -

> Users would get the stack address of the stack they want to share
through pthread_attr_getstack(). Now, when they get the address they want
to share, they would pass the appropriate name of this memory-region. What
we have to provide is a mechanism to 'convert' this address to an
appropriate name. Is this the accepted way or the other way round, i.e. the
user passes a name as per a specified convention, and that name is
'converted' to a specific address?

> When you say "treating the entire task stack as a single named object"
does it mean that we assign a single name, say "task_stack" to the complete
stack address space? In that case, how do we deal we the presence of
multiple tasks that are allocated from the same pool of task stack? I
understand that on a simpler MPU/MMU hardware it would make sense to
specify names for each memory section (.txt- "text", .bss - "bss" etc.) but
in this case,  where we are sharing only selected thread-stacks, I suppose
we will have to have a way to handle 'offsets' right from the start?


> Gedare
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Converting stack address to shared-memory object name

[Utkarsh Rai]

Hello,
For my GSoC project, I have to provide high-level APIs for sharing isolated
stacks.
The POSIX compliant high-level way of sharing stacks can be to create a
shared memory object of the stack to be shared through shm_open and then
mmap that to the address space of the current stack. My doubt is,
shm_open() takes the path-name of the shared memory object. Since this is a
high-level API, how does the user 'convert' the stack address to a shared
memory object name?

Dr.Gedare mentioned that one way to deal with naming would be something
like Mr.Sebastian has been doing with specifications. From what I could
gather, it is a hierarchical way of representing objects(Though, I am not
very sure if  I understand this accurately). How can something like this be
implemented for naming stack-addresses?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Applying an operation to a set of threads in RTEMS

[Utkarsh Rai]

On Sat, Jul 4, 2020 at 1:13 AM  wrote:

> This thought is intended to be evaluated, not adopted.  What I meant was I
> think you have a "bitmask" of threads that need access to a stack that is
> similar to a "bitmask" of threads/processes that may be blocked in select.
> The select-mask is a major focus across operating systems.  That's why I
> thought that if you consider it to be equivalent you should use that
> interface.
>
>
Oh, that makes more sense. Thank you for the clarification!

> On Jul 3, 2020, at 08:42 , dufa...@hda.com wrote:
> >
> > My thought is that it matches what is needed and is expected to be
> optimized.
> >
> >> On Jul 3, 2020, at 24:37 , Utkarsh Rai  wrote:
> >>
> >>
> >>
> >> On Fri, Jul 3, 2020 at 1:32 AM Peter Dufault  wrote:
> >> I finally have gotten to reviewing Utkarsh's work in GSOC.  One item
> that I don't like is that there is a linked list management of the threads
> that have access to the stack.
> >> I think this access is similar to the file descriptors that are blocked
> in a select call.  On a given architecture I don't know exactly how many
> file descriptors I can block, I don't know exactly what the FD_SET macro
> does, but I have access to multiple file descriptors through the FD_*
> macros.
> >>
> >>
> >> Hello, thank you for the feedback. If I understand your suggestion
> correctly, we can specify a file descriptor set 'fd_set' and then register
> the stack attributes to this set, and then check for the 'current stack'
> through select() and FD_ISSET()?
> >>
> >> Using FD_SET and friends for specifying thread access could be a good
> model to specify which threads need access to which thread.
> >>
> >> My question is,  what benefit do we get by using FD_SET and friends?
> Ultimately we will have to iterate through the set to check for the
> 'current stack'.
> >>
> >> However, it won't scale infinitely.  Linked lists won't scale
> infinitely in real-time either.
> >>
> >> An optimization that I had in mind was to use the LRU model. This way
> we can mark the stack attributes of the last thread as 'not current'
> without iterating through the list or the set.
> >>
> >> 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.
> >>
> >
> > 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
>
> 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

Re: Applying an operation to a set of threads in RTEMS

[Utkarsh Rai]

On Fri, Jul 3, 2020 at 1:32 AM Peter Dufault  wrote:

> I finally have gotten to reviewing Utkarsh's work in GSOC.  One item that
> I don't like is that there is a linked list management of the threads that
> have access to the stack.
> I think this access is similar to the file descriptors that are blocked in
> a select call.  On a given architecture I don't know exactly how many file
> descriptors I can block, I don't know exactly what the FD_SET macro does,
> but I have access to multiple file descriptors through the FD_* macros.
>
>
Hello, thank you for the feedback. If I understand your suggestion
correctly, we can specify a file descriptor set 'fd_set' and then register
the stack attributes to this set, and then check for the 'current stack'
through select() and FD_ISSET()?

Using FD_SET and friends for specifying thread access could be a good model
> to specify which threads need access to which thread.
>

My question is,  what benefit do we get by using FD_SET and friends?
Ultimately we will have to iterate through the set to check for the
'current stack'.


> However, it won't scale infinitely.  Linked lists won't scale infinitely
> in real-time either.


An optimization that I had in mind was to use the LRU model. This way we
can mark the stack attributes of the last thread as 'not current' without
iterating through the list or the set.

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

Re: [PATCH] Assembly suppport for context switch and bug fixes

[Utkarsh Rai]

On Mon, Jun 29, 2020 at 11:00 PM Gedare Bloom  wrote:

> high-level comment: this patch is not complete wrt current RTEMS
> master branch. This makes a complete review impossible. I'm not even
> sure what I'm supposed to be reviewing here.


Sorry, I was undecided between sending all of my changes in multiple
patches or squashing the last few which had the context-switching mechanism
that I wanted to get reviewed.


> I did my best to provide
> you with some guidance, but if you want something specific
> reviewed/evaluated, please make a clean patch that demonstrates your
> idea for review.


Should I squash all of my commits and send it as a single patch (along with
the changes suggested in this one) or break it into multiple patches?


>   More below:
>
> On Mon, Jun 29, 2020 at 8:48 AM utkarsh.ra...@gmail.com
>  wrote:
> >
> > From: Utkarsh Rai 
> >
> > ---
> >  cpukit/score/cpu/arm/cpu.c|  3 +-
> >  cpukit/score/cpu/arm/cpu_asm.S| 14 ++-
> >  .../score/cpu/arm/include/rtems/score/cpu.h   | 12 ++-
> >  cpukit/score/src/stackmanagement.c| 98 +++
> >  cpukit/score/src/threadloadenv.c  | 11 +++
> >  5 files changed, 92 insertions(+), 46 deletions(-)
> >
> > diff --git a/cpukit/score/cpu/arm/cpu.c b/cpukit/score/cpu/arm/cpu.c
> > index 5ee1acede2..39b5a33c03 100644
> > --- a/cpukit/score/cpu/arm/cpu.c
> > +++ b/cpukit/score/cpu/arm/cpu.c
> > @@ -97,8 +97,9 @@ void _CPU_Context_Initialize(
> >  )
> >  {
> >(void) new_level;
> > -
> Don't remove/add blank lines in existing files without good reason. I
> don't know if it is codified, but we usually have a blank line after
> variable decls.
>
> > +  #if defined (USE_THREAD_STACK_PROTECTION)
> >the_context->stack_attr = prot_stack_context_initialize();
> This appears to be a line that was added prior? Please check out how
> to "squash" multiple patches together to a single patch. That will
> help with review. I like to use the "git rebase -i" interactive rebase
> mode for patch management.
>
> An "attribute" is normally a property of something. So is this storing
> some (set of) properties for the thread's stack?
>
> We prefer to avoid abbreviations in function names when possible. We
> also need to be aware of namespace issues. this "prot_" should belong
> to some namespace that is cleanly separated from applications.
>
> > +  #endif
> >the_context->register_sp = (uint32_t) stack_area_begin +
> stack_area_size;
> >the_context->register_lr = (uint32_t) entry_point;
> >the_context->isr_dispatch_disable = 0;
> > diff --git a/cpukit/score/cpu/arm/cpu_asm.S
> b/cpukit/score/cpu/arm/cpu_asm.S
> > index e7cdd24c2f..2678589483 100644
> > --- a/cpukit/score/cpu/arm/cpu_asm.S
> > +++ b/cpukit/score/cpu/arm/cpu_asm.S
> > @@ -65,9 +65,13 @@ DEFINE_FUNCTION_ARM(_CPU_Context_switch)
> >  #endif
> >
> > str r3, [r0, #ARM_CONTEXT_CONTROL_ISR_DISPATCH_DISABLE]
> > -   str r0, [r0, #44]
> why this is removed? what is it from? this line is something from a
> prior patch you have not sent?
>
> > +#if defined ( USE_THREAD_STACK_PROTECTION )
> > +mov r2, r0
> > +   ldr r0, [r0, #ARM_STACK_PROT_ATTR_OFFSET]
> check number of white spaces in alignment here.  why it is indented
> more than surrounding lines?
>
> Should this macro should be consistent with similar macros? Like
> ARM_CONTEXT_CONTROL_STACK_ATTR_OFFSET
>
> > bl  prot_stack_context_switch
> again, this is from some prior patch that you haven't sent, so I can't
> review it here.
>
> > -
> > +   mov r0, r2
> > +#endif
> > +
> >  #ifdef RTEMS_SMP
> > /*
> >  * The executing thread no longer executes on this processor.
> Switch
> > @@ -135,6 +139,12 @@ DEFINE_FUNCTION_ARM(_CPU_Context_switch)
> >   */
> >  DEFINE_FUNCTION_ARM(_CPU_Context_restore)
> >  mov r1, r0
> > +#if defined( USE_THREAD_STACK_PROTECTION )
> > +   ldr r2,  [lr]
> > +   ldr r0, [r0, #ARM_STACK_PROT_ATTR_OFFSET]
> indent?
>
> > +   bl  prot_stack_context_restore
> > +   ldr lr, [r2]
> > +#endif
> > GET_SELF_CPU_CONTROLr2
> >  b   .L_restore
> >
> > diff --git a/cpukit/score/cpu/arm/include/rtems/score/cpu.h
> b/cpukit/score/cpu/arm/include/rtems/score/cpu.h
> > index 481d50f427..f0af63e532 100644
> > --- a/cpukit/score/cpu/arm/include/rtems/score/cpu.h
> 

Verfication of context-switching mechanism for protected stacks

[Utkarsh Rai]

The following patch provides a context-switching mechanism for protected
stacks. This is not a mergeable patch. I want to have feedback on the
mechanism.
> I have added 'stack_attribute' to the 'Context_Control' structure.
> On a call to 'Context_Initialize()'. the 'stack_attribute' field is
initialized with attributes of the current thread.
> On each context-switch we branch to the 'prot_stack_context_switch()'
which unsets the memory attributes of the currently executing thread-stack.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Offset locations of registers in ARM context-switch code

[Utkarsh Rai]

Hello,
The 'Context_Control' structure in score/.../arm/cpu.h has registers and
attributes that need to be saved during context-switching.
Some of these registers/attributes are conditionally compiled depending
upon the mode in which the processor is running. The registers are saved by
'ldr' instruction by providing proper offset form the context-control base
address. These offsets are dependent on the mode for which the compilation
is done.
For example, the 'is_executing' attribute has the following offset,
depending on various modes.
''
#ifdef RTEMS_SMP
  #if defined(ARM_MULTILIB_VFP)
#define ARM_CONTEXT_CONTROL_IS_EXECUTING_OFFSET 112
  #elif defined(ARM_MULTILIB_HAS_THREAD_ID_REGISTER)
#define ARM_CONTEXT_CONTROL_IS_EXECUTING_OFFSET 48
  #else
#define ARM_CONTEXT_CONTROL_IS_EXECUTING_OFFSET 44
  #endif
#endif ''

My question is, what are the modes for which different registers in the
context control structure are compiled?
This is important to me as I have added a protected stack attribute to the
structure and I need to define a similar offset for this depending upon the
cpu mode.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Context switching for protected stacks

[Utkarsh Rai]

On Fri, Jun 19, 2020 at 3:04 AM Gedare Bloom  wrote:

> On Thu, Jun 18, 2020 at 8:03 AM Utkarsh Rai 
> wrote:
> >
> >
> >
> > On Thu, Jun 18, 2020 at 6:34 PM Gedare Bloom  wrote:
> >>
> >> On Wed, Jun 17, 2020 at 11:17 PM Utkarsh Rai 
> wrote:
> >> >
> >> > Hello,
> >> > For my GSoC project, I need to set/unset the memory attributes of the
> thread stacks on each context switch.
> >> > Right now I am making changes to the CPU-specific context switch
> assembly code. The arm/../cpu.h file has the Context_Control structure,
> which is used to store the relevant registers at each context switch.
> >> >  I have been trying to add the stack attributes to this structure
> from the 'rtems/score/stackmanagement.h' header (This header has been
> defined by me and has the stack attributes structure).
> >>
> >> When you change the context structure, there might be other places you
> >> need to update besides the context switch itself. One that comes to
> >> mind is _CPU_Context_validate. Maybe chase down where the context is
> >> referenced.
> >>
> >> >  After that, I would initialize the stack attributes in
> _CPU_Context_Initialize.
> >> >  For unsetting stack memories, I plan on making changes to
> _CPU_Context_Switch().
> >> > The problem is when I try to include the header in cpu.h it breaks
> the build with the following error -
> >> >
> >> > '...
> >> > 
> >> >
> /home/utkarsh/sandbox/rtems/5/arm-rtems5/include/machine/_default_types.h:
> Assembler messages:
> >> >
> /home/utkarsh/sandbox/rtems/cpukit/include/rtems/score/stackmanagement.h:42:
> Error: junk at end of line, first unrecognized character is `}'
> >> >
> /home/utkarsh/sandbox/rtems/cpukit/include/rtems/score/stackmanagement.h:44:
> Error: bad instruction `typedef struct stack_attr_prot'
> >> >
> /home/utkarsh/sandbox/rtems/cpukit/include/rtems/score/stackmanagement.h:45:
> Error: junk at end of line, first unrecognized character is `{'
> >> >
> /home/utkarsh/sandbox/rtems/cpukit/include/rtems/score/stackmanagement.h:46:
> Error: bad instruction `stack_attr_shared *shared_stacks'
> >> >
> /home/utkarsh/sandbox/rtems/cpukit/include/rtems/score/stackmanagement.h:47:
> Error: bad instruction `stack_attr Base'
> >> >
> /home/utkarsh/sandbox/rtems/cpukit/include/rtems/score/stackmanagement.h:48:
> Error: bad instruction `_bool current_stack'
> >> > {standard input}: Error: invalid operands (*UND* and *ABS* sections)
> for `*' when setting `iter'
> >> > Makefile:11563: recipe for target
> 'score/cpu/arm/arm-context-validate.o' failed
> >> > make[4]: *** [score/cpu/arm/arm-context-validate.o] Error 1
> >> > '
> >> > I have defined the stackmanagement.h header in the cpukit/headers.am
> and this is obviously an assembler error.  Can someone point out what is it
> that I am doing wrong?
> >> >
> >>
> >> When a .h file can be included in both C and ASM, you need to separate
> >> some of it, and disable some of it in ASM scope that doesn't
> >> understand C data types. See, for example,
> >> cpukit/include/rtems/score/percpu.h
> >>
>

Thank you, this solves the problem.


> >> > I also would like to verify if the above way of handling context
> switching is the appropriate way to proceed.
> >>
> >> Seems like the right general idea. We probably need a CPP switch to
> >> enable/disable this stuff though.
> >
> >
> > Can you please elaborate on CPP switch? I am not sure if I am clear
> about this.
>
> Yeah, my reply was a little short. CPP for C Preprocessor. A CPP
> switch is used for conditional compilation of code, something like
>
> #if defined(USE_MMU)
> ... /* some MMU related code */
> #else
> ... /* something without using MMU */
> #endif
>
> This way high-level features can control which code gets compiled into
> the binary image. This works pretty well for coarse-grained features.
> It is not that useful for finer-grained features, like you might not
> want to have USE_MMU_2K_PAGES and USE_MMU_4K_PAGES and
> USE_MMU_4M_PAGES instead it would be better to have USE_MMU and within
> that scope provide some way to distinguish the page sizes. I hope that
> makes some sense.
>
> Another example is ASM. We have #if ASM to control whether a header
> has been included in an assembler source file.
>

Thank you, this makes it clear. Also, if we are using CPP switches for
switching to MMU related code, I wonder what should be the high-level
configuration option that should be provided to the user. A very naive way
can be if the user defines something like-
 #define USE_THREAD_STACK_PROTECTION

and then the places where we need to handle for thread stack protection we
can proceed as you illustrate above.

Gedare
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Context switching for protected stacks

[Utkarsh Rai]

On Thu, Jun 18, 2020 at 6:34 PM Gedare Bloom  wrote:

> On Wed, Jun 17, 2020 at 11:17 PM Utkarsh Rai 
> wrote:
> >
> > Hello,
> > For my GSoC project, I need to set/unset the memory attributes of the
> thread stacks on each context switch.
> > Right now I am making changes to the CPU-specific context switch
> assembly code. The arm/../cpu.h file has the Context_Control structure,
> which is used to store the relevant registers at each context switch.
> >  I have been trying to add the stack attributes to this structure from
> the 'rtems/score/stackmanagement.h' header (This header has been defined by
> me and has the stack attributes structure).
>
> When you change the context structure, there might be other places you
> need to update besides the context switch itself. One that comes to
> mind is _CPU_Context_validate. Maybe chase down where the context is
> referenced.
>
> >  After that, I would initialize the stack attributes in
> _CPU_Context_Initialize.
> >  For unsetting stack memories, I plan on making changes to
> _CPU_Context_Switch().
> > The problem is when I try to include the header in cpu.h it breaks the
> build with the following error -
> >
> > '...
> > 
> >
> /home/utkarsh/sandbox/rtems/5/arm-rtems5/include/machine/_default_types.h:
> Assembler messages:
> >
> /home/utkarsh/sandbox/rtems/cpukit/include/rtems/score/stackmanagement.h:42:
> Error: junk at end of line, first unrecognized character is `}'
> >
> /home/utkarsh/sandbox/rtems/cpukit/include/rtems/score/stackmanagement.h:44:
> Error: bad instruction `typedef struct stack_attr_prot'
> >
> /home/utkarsh/sandbox/rtems/cpukit/include/rtems/score/stackmanagement.h:45:
> Error: junk at end of line, first unrecognized character is `{'
> >
> /home/utkarsh/sandbox/rtems/cpukit/include/rtems/score/stackmanagement.h:46:
> Error: bad instruction `stack_attr_shared *shared_stacks'
> >
> /home/utkarsh/sandbox/rtems/cpukit/include/rtems/score/stackmanagement.h:47:
> Error: bad instruction `stack_attr Base'
> >
> /home/utkarsh/sandbox/rtems/cpukit/include/rtems/score/stackmanagement.h:48:
> Error: bad instruction `_bool current_stack'
> > {standard input}: Error: invalid operands (*UND* and *ABS* sections) for
> `*' when setting `iter'
> > Makefile:11563: recipe for target 'score/cpu/arm/arm-context-validate.o'
> failed
> > make[4]: *** [score/cpu/arm/arm-context-validate.o] Error 1
> > '
> > I have defined the stackmanagement.h header in the cpukit/headers.am
> and this is obviously an assembler error.  Can someone point out what is it
> that I am doing wrong?
> >
>
> When a .h file can be included in both C and ASM, you need to separate
> some of it, and disable some of it in ASM scope that doesn't
> understand C data types. See, for example,
> cpukit/include/rtems/score/percpu.h
>
> > I also would like to verify if the above way of handling context
> switching is the appropriate way to proceed.
>
> Seems like the right general idea. We probably need a CPP switch to
> enable/disable this stuff though.
>

Can you please elaborate on CPP switch? I am not sure if I am clear about
this.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Context switching for protected stacks

[Utkarsh Rai]

Hello,
For my GSoC project, I need to set/unset the memory attributes of the
thread stacks on each context switch.
Right now I am making changes to the CPU-specific context switch assembly
code. The arm/../cpu.h file has the Context_Control structure, which is
used to store the relevant registers at each context switch.
 I have been trying to add the stack attributes to this structure from the
'rtems/score/stackmanagement.h' header (This header has been defined by me
and has the stack attributes structure).
 After that, I would initialize the stack attributes in
_CPU_Context_Initialize.
 For unsetting stack memories, I plan on making changes
to _CPU_Context_Switch().
The problem is when I try to include the header in cpu.h it breaks the
build with the following error -

'...

/home/utkarsh/sandbox/rtems/5/arm-rtems5/include/machine/_default_types.h:
Assembler messages:
/home/utkarsh/sandbox/rtems/cpukit/include/rtems/score/stackmanagement.h:42:
Error: junk at end of line, first unrecognized character is `}'
/home/utkarsh/sandbox/rtems/cpukit/include/rtems/score/stackmanagement.h:44:
Error: bad instruction `typedef struct stack_attr_prot'
/home/utkarsh/sandbox/rtems/cpukit/include/rtems/score/stackmanagement.h:45:
Error: junk at end of line, first unrecognized character is `{'
/home/utkarsh/sandbox/rtems/cpukit/include/rtems/score/stackmanagement.h:46:
Error: bad instruction `stack_attr_shared *shared_stacks'
/home/utkarsh/sandbox/rtems/cpukit/include/rtems/score/stackmanagement.h:47:
Error: bad instruction `stack_attr Base'
/home/utkarsh/sandbox/rtems/cpukit/include/rtems/score/stackmanagement.h:48:
Error: bad instruction `_bool current_stack'
{standard input}: Error: invalid operands (*UND* and *ABS* sections) for
`*' when setting `iter'
Makefile:11563: recipe for target 'score/cpu/arm/arm-context-validate.o'
failed
make[4]: *** [score/cpu/arm/arm-context-validate.o] Error 1
'
I have defined the stackmanagement.h header in the cpukit/headers.am and
this is obviously an assembler error.  Can someone point out what is it
that I am doing wrong?

I also would like to verify if the above way of handling context switching
is the appropriate way to proceed.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Help in figuring out score objects in RTEMS and ticket #3131

[Utkarsh Rai]

On Mon, Jun 15, 2020 at 6:46 PM Joel Sherrill  wrote:

>
>
> On Wed, Jun 10, 2020 at 7:34 PM Utkarsh Rai 
> wrote:
>
>> Hello,
>> For my GSoC project, user-configurable thread stack protection, I need to
>> track, allocate, and manipulate attributes of shared as well as protected
>> stacks. Dr.Gedare suggested that tracking them with score objects would be
>> a good idea. He also indicated a good place to start and understand
>> score objects would be through this ticket.
>> <https://devel.rtems.org/ticket/3131>
>>
>> From the information that I could find in docs, my understanding of score
>> objects is that they are a type of directive that
>> helps introduce modularity to RTEMS as various types of RTEMS objects like
>> message queues, semaphores, etc. can use the same set of directives for
>> allocation/deallocation and control of their object types.
>>
>
> It is probably easier for you to think about the score as a collection of
> core classes that are reused across the public APIs. They do have strong
> modularity but they also ensure that the correct and optimized behavior is
> present across both the Classic and POSIX APIs. For example, a mutex can be
> optimized and made computer science correct just once and both the POSIX
> and Classic APIs benefit. Whether you call this layering, modularity,
> packaging, or classes is OK.
>
> If you look at the Doxygen, you will see there is even a bit of
> inheritance.
>
>
>> Some of the examples of the implementation that I could find used
>> _Object_Iniitialize_information()
>> to initialize the object type, then _Object_Allocate()/Free()
>> allocate/de-allocate the object. Object_Id is used to control the object
>> type. My confusion is, how do we use object IDs to refer to and control the
>> allocated objects?
>>
>
> Every public API with an ID uses the score Object Handler to convert that
> ID into an instance to an object (base class) which is cast to an instance
> of the proper API type. An object has a name, ID, and a chain node. Any
> object can be put on lists. This is important because that's how the
> inactive set of each class of objects is managed. Various things are put on
> FIFO lists.
>
> The Chain handler which defines the Node structure and the Red-Black Tree
> are the foundation of many RTEMS data structures/algorithms.
>

In the case of my project, I need to track and set the attributes of
protected and shared stacks. The current implementation looks like this
<https://github.com/ur10/rtems/blob/test_branch/cpukit/score/src/stack_management.c>,
maybe the APIs need to be in the public space, and if not, the stacks need
to be tracked by score objects. I suppose the important question is,  what
are the expectations as to how a mergeable implementation of this should
look like?


>
>>
>> I also have some confusion in the above-mentioned ticket, it says-
>> 'The mmap_h handler should construct a mapping object. A destructor is
>> currently missing. Maybe the mmap_h handler should use a flag to deal with
>> construction and destruction.'
>>  I am unclear as to how the mmap_h handler should precisely look like
>> and where should it be defined?
>>
>
> I don't think this will be useful for your project. This is only used to
> provide a BSP specific mechanism to attach memory. This is primarily used
> in paravirtualized environments to allow the BSP to map memory shared with
> other address spaces. Without a hypervisor or host under RTEMS, this isn't
> going to be used. Although I think Gedare has at least one use case beyond
> this for it.
>
> I think the stack allocator/deallocator hooks will be more useful.
>

>
>> I would be grateful if you can provide some help in figuring this out.
>>
>> Regards,
>> Utkarsh
>>
>> ___
>> 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 in figuring out score objects in RTEMS and ticket #3131

[Utkarsh Rai]

With the help of Dr.Gedare and a bit of digging, I was able to understand
the file system design concept in RTEMS. This is what I was able to gather-

 > The object-oriented design of the file system refers to the fact that
the virtual file-system layer provides a framework upon which different
filesystems can be built.

> For example, the file_sytems_operations_table defines the various
operations required by a file system(mount, unmount, path evaluation), the
rtems_filesystem_file_handlers_r table defines the various functions(open,
write, read, etc.) that act on a node in a file-system also this is where
the mmap_h handler is defined.

>The file system defines its implementation of the above operations and
registers it in the corresponding table, whenever a system call is made,
the registered handler is invoked and changes to the file are done.

So my question is,  do we have to define the mmap_h in the IMFS file system
layer(as I could not find an implementation for this handler) and then
register it in the file_handlers table and then use this in mmap? Or do we
already have a generic mmap_h implementation that I can use?


On Thu, Jun 11, 2020 at 6:04 AM Utkarsh Rai  wrote:

> Hello,
> For my GSoC project, user-configurable thread stack protection, I need to
> track, allocate, and manipulate attributes of shared as well as protected
> stacks. Dr.Gedare suggested that tracking them with score objects would be
> a good idea. He also indicated a good place to start and understand
> score objects would be through this ticket.
> <https://devel.rtems.org/ticket/3131>
>
> From the information that I could find in docs, my understanding of score
> objects is that they are a type of directive that
> helps introduce modularity to RTEMS as various types of RTEMS objects like
> message queues, semaphores, etc. can use the same set of directives for
> allocation/deallocation and control of their object types.
>
> Some of the examples of the implementation that I could find used
> _Object_Iniitialize_information()
> to initialize the object type, then _Object_Allocate()/Free()
> allocate/de-allocate the object. Object_Id is used to control the object
> type. My confusion is, how do we use object IDs to refer to and control the
> allocated objects?
>
> I also have some confusion in the above-mentioned ticket, it says-
> 'The mmap_h handler should construct a mapping object. A destructor is
> currently missing. Maybe the mmap_h handler should use a flag to deal with
> construction and destruction.'
>  I am unclear as to how the mmap_h handler should precisely look like and
> where should it be defined?
> I would be grateful if you can provide some help in figuring this out.
>
> Regards,
> Utkarsh
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Help in figuring out score objects in RTEMS and ticket #3131

[Utkarsh Rai]

Hello,
For my GSoC project, user-configurable thread stack protection, I need to
track, allocate, and manipulate attributes of shared as well as protected
stacks. Dr.Gedare suggested that tracking them with score objects would be
a good idea. He also indicated a good place to start and understand
score objects would be through this ticket.


>From the information that I could find in docs, my understanding of score
objects is that they are a type of directive that
helps introduce modularity to RTEMS as various types of RTEMS objects like
message queues, semaphores, etc. can use the same set of directives for
allocation/deallocation and control of their object types.

Some of the examples of the implementation that I could find used
_Object_Iniitialize_information()
to initialize the object type, then _Object_Allocate()/Free()
allocate/de-allocate the object. Object_Id is used to control the object
type. My confusion is, how do we use object IDs to refer to and control the
allocated objects?

I also have some confusion in the above-mentioned ticket, it says-
'The mmap_h handler should construct a mapping object. A destructor is
currently missing. Maybe the mmap_h handler should use a flag to deal with
construction and destruction.'
 I am unclear as to how the mmap_h handler should precisely look like and
where should it be defined?
I would be grateful if you can provide some help in figuring this out.

Regards,
Utkarsh
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Setting up the TTBR0 and TTBR1 register for thread stack protection in ARMv7-A MMU

[Utkarsh Rai]

On Fri, Jun 5, 2020 at 6:19 PM Hesham Almatary 
wrote:

> Hello Utkarsh,
>
> TTBR1 is there primarily for UNIX-like kernels to be re-mapped at very
> high addresses and user space can use TTBR0. In the case of RTEMS, we
> don't have that user vs kernel separation. Furthermore, using TTBR1
> won't allow us to do 1:1 fixed mappings.
>
>
I agree, sorry, after looking around a bit more I realized some of the
above limitations.


> Could you give more details why having different page sizes would be
> an issue? You would normally have multi-level page tables for more
> fine-grained page sizes.


No this will not be an issue, we can set the bits[1:0]  of the table-entry
to account for the levels of page tables. I was thinking about ways to
simplify the implementation of stack allocation, but doing this is
definitely not feasible.


>
On Thu, 4 Jun 2020 at 11:44, Utkarsh Rai  wrote:
> >
> > Hello,
> >
> > Section B3.3.3 of the ARMv7-A Reference manual says that we can have
> TTBR0 and 1 split up the address space into two parts, where each register
> has the address of the translation table base
> > of the divided address space.
> > One of the ways to simplify the implementation of thread-stack
> protection in ARMv7-A MMU can be, to have the global statically allocated
> sections being pointed by the TTBR1 register and the work-space area being
> pointed out by the TTBR0 register. This way during context switch we would
> only have to change the TTBR0 register, this would also simplify the
> implementation as we won't have to worry about addresses of different page
> sizes being pointed by the same translation-table base.
> > In the current implementation, TTB is put in TTBR0, and TTBR1 is not
> used.
> > Is the above-suggested implementation feasible?
> >
> > Regards,
> > Utkarsh
>
>
>
> --
> Hesham
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Setting up the TTBR0 and TTBR1 register for thread stack protection in ARMv7-A MMU

[Utkarsh Rai]

Hello,

Section B3.3.3 of the ARMv7-A Reference manual

says that we can have TTBR0 and 1 split up the address space into two
parts, where each register has the address of the translation table base
of the divided address space.
One of the ways to simplify the implementation of thread-stack protection
in ARMv7-A MMU can be, to have the global statically allocated sections
being pointed by the TTBR1 register and the work-space area being pointed
out by the TTBR0 register. This way during context switch we would only
have to change the TTBR0 register, this would also simplify the
implementation as we won't have to worry about addresses of different page
sizes being pointed by the same translation-table base.
In the current implementation, TTB is put in TTBR0, and TTBR1 is not used.
Is the above-suggested implementation feasible?

Regards,
Utkarsh
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Error in building application with rpi BSP with waf build system

[Utkarsh Rai]

On Mon, Jun 1, 2020 at 9:32 AM Utkarsh Rai  wrote:

> Hello,
>
> I was unable to build a sample app for raspberrypi, I followed the docs
> <https://docs.rtems.org/branches/master/user/start/app.html> and was able
> to build the app for Xilinx-qemu and beagleboard.
>
> The waf configure command was - ./waf configure
> --rtems=$HOME/sandbox/rtems/5 --rtems-bsp=arm/raspberrypi
>
> The log file shows the following message-
> "
> # project  configured on Mon Jun  1 09:19:15 2020 by
> # waf 2.0.19 (abi 20, python 20711f0 on linux2)
> # using ./waf configure --rtems=/home/utkarsh/sandbox/rtems/5
> --rtems-bsp=arm/raspberrypi
> #
> 
> Setting top to
> /home/utkarsh/Desktop/rtems_test
> 
> Setting out to
> /home/utkarsh/Desktop/rtems_test/build
> from /home/utkarsh/Desktop/rtems_test: No valid arch/bsps found"
>
> A ./rtems-bsps shows that the valid BSP name for RPI is the same as that
> in configure command.
> Is there a typo in my configure command or the waf build does not support
> raspberrypi BSP? Kindly point out my error.
>
> Regards,
> Utkarsh Rai.
>

Sorry, this is resolved, I had deleted my RPI BSP build and was then trying
to build the app.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Error in building application with rpi BSP with waf build system

[Utkarsh Rai]

Hello,

I was unable to build a sample app for raspberrypi, I followed the docs
<https://docs.rtems.org/branches/master/user/start/app.html> and was able
to build the app for Xilinx-qemu and beagleboard.

The waf configure command was - ./waf configure
--rtems=$HOME/sandbox/rtems/5 --rtems-bsp=arm/raspberrypi

The log file shows the following message-
"
# project  configured on Mon Jun  1 09:19:15 2020 by
# waf 2.0.19 (abi 20, python 20711f0 on linux2)
# using ./waf configure --rtems=/home/utkarsh/sandbox/rtems/5
--rtems-bsp=arm/raspberrypi
#

Setting top to
/home/utkarsh/Desktop/rtems_test

Setting out to
/home/utkarsh/Desktop/rtems_test/build
from /home/utkarsh/Desktop/rtems_test: No valid arch/bsps found"

A ./rtems-bsps shows that the valid BSP name for RPI is the same as that in
configure command.
Is there a typo in my configure command or the waf build does not support
raspberrypi BSP? Kindly point out my error.

Regards,
Utkarsh Rai.
___
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 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. p