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

[Utkarsh Rai]

On Tue, Jan 26, 2021 at 9:33 PM Gedare Bloom <gedare at rtems.org> wrote:

>
>
> On Tue, Jan 26, 2021 at 8:24 AM Sebastian Huber <
> sebastian.huber at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210127/65a6cf25/attachment.html>