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

[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( &config );
+   if (exit_code == 0) {
+   TEST_END();
+ 

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

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

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

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

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

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]

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: [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 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]

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 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( &lock_context );

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

-  if ( executing != NULL ) {
-iter.previous = executing->last_user_extensions_iterator;
-executing->last_user_extensions_iterator = &iter;
+while ( ( node = _Chai

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(..., &events, ...);
> >
> 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: [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

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, &access_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, &access_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(
 &the_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
--- a/cpukit/rtems/

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, &access_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, &access_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(
>>  &the_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

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, &access_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 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, &access_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, &access_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_messa

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, &access_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, &access_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 d

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: 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: 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: 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 - 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,
>> >>> H

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

[Utkarsh Rai]

On Wed, Apr 15, 2020 at 10:26 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> 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.
>
Would it be alright to add the test cases for clock nanosleep in
psxtests/psxclock? I had two test cases in mind-
To check for a simple desired delay and to check that clock_nanosleep
produces the required delay with CLOCK_MONOTONIC even when CLOCK_REALTIME
is modified.

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_TEST_CHECK([psxcleanup02])
> >   RTEMS_TEST_CHECK([psxclock])
> >   RTEMS_TEST_CHECK([psxclock01])
> > +RTEMS_TEST_CHECK([psxclocknanosleep01])
> >   RTEMS_TEST_CHECK([psxclockrealtime01])
> >   RTEMS_TEST_CHECK([psxconcurrency01])
> >   RTEMS_TEST_CHECK([psxcond01])
> > diff --git a/testsuites/psxtests/psxclocknanosleep01/init.c
> b/testsuites/psxtests/psxclocknanosleep01/init.c
> > new file mode 100644
> > index 00..21b738627d
> > --- /dev/null
> > +++ b/testsuites/psxtests/psxclocknanosleep01/init.c
> > @@ -0,0 +1,81 @@
> > +/*
> > + * 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 

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

[Utkarsh Rai]

On Wed, Apr 15, 2020 at 5:35 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 15/04/2020 14:02, Utkarsh Rai wrote:
>
> > +  status = clock_gettime( CLOCK_MONOTONIC, &end_time );
>> > +  rtems_test_assert( status == 0 );
>> > +
>> > +  rtems_test_assert( (end_time.tv_sec-init_time.tv_sec) == 0 );
>>
>> Is end_time.tv_sec - init_time.tv_sec == 0 under all circumstances?
>>
>
> My idea was to check for a 1ns delay with a reasonable amount of overhead,
> hence I checked for  end_time.tv_sec - init_time.tv_sec == 0.
>
> Exists there a value of init_time for which end_time.tv_sec !=
> init_time.tv_sec and still 1ns elapsed?
>

Sorry, maybe I am confused in my concept, kidly help me out. I want to
produce a 1ns delay, so I make a call to clock_nanosleep with flag value as
0 (to sleep for specified time) and the delay being 1ns. I recorded the
time before the sleep call and after the sleep call. Now, I want to check
if the delay produced was actually 1ns with a reasonable overhead, my
assumption for an unreasonable overhead was that if I specify a delay of
1ns and I get a delay in seconds, it would be an error.
___
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]

Okay, so from what I could gather the time between the two gettime calls
can exceed 1 sec if it is preempted by another process in between. Is my
line of thought correct?

On Wed, Apr 15, 2020 at 6:01 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
> On 15/04/2020 14:29, Utkarsh Rai wrote:
>
> On Wed, Apr 15, 2020 at 5:35 PM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 15/04/2020 14:02, Utkarsh Rai wrote:
>>
>> > +  status = clock_gettime( CLOCK_MONOTONIC, &end_time );
>>> > +  rtems_test_assert( status == 0 );
>>> > +
>>> > +  rtems_test_assert( (end_time.tv_sec-init_time.tv_sec) == 0 );
>>>
>>> Is end_time.tv_sec - init_time.tv_sec == 0 under all circumstances?
>>>
>>
>> My idea was to check for a 1ns delay with a reasonable amount of
>> overhead, hence I checked for  end_time.tv_sec - init_time.tv_sec == 0.
>>
>> Exists there a value of init_time for which end_time.tv_sec !=
>> init_time.tv_sec and still 1ns elapsed?
>>
>
> Sorry, maybe I am confused in my concept, kidly help me out. I want to
> produce a 1ns delay, so I make a call to clock_nanosleep with flag value as
> 0 (to sleep for specified time) and the delay being 1ns. I recorded the
> time before the sleep call and after the sleep call. Now, I want to check
> if the delay produced was actually 1ns with a reasonable overhead, my
> assumption for an unreasonable overhead was that if I specify a delay of
> 1ns
>
> Up to here everything is fine.
>
> and I get a delay in seconds, it would be an error.
>
> Think about this once more.
>
___
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]

Yes sir.

On Wed 15 Apr, 2020, 7:21 PM Sebastian Huber, <
sebastian.hu...@embedded-brains.de> wrote:

> On 15/04/2020 15:00, Utkarsh Rai wrote:
>
> > Okay, so from what I could gather the time between the two gettime
> > calls can exceed 1 sec if it is preempted by another process in
> > between. Is my line of thought correct?
> There is no other process. What you want to know is if the difference
> between two struct timespec is greater than or equal to 1ns, right?
>
___
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]

Oh, I missed that, basically the difference between the second would amount
to 59 and hence my assumption would be wrong
Thank you for the clarification, I will remember to consider the cases.

On Wed 15 Apr, 2020, 7:37 PM Gedare Bloom,  wrote:

> I appreciate what Sebastian is doing, but I'll be a bit more explicit.
> You should understand what resources/APIs already exist that may help
> you, such as:
> https://docs.rtems.org/branches/master/c-user/timespec_helpers.html#timespec-helpers
>
> What happens when the time is 11:59:59.9 (HH:MM:SS.mmmuuunnn)
> and you delay for 1 ns?
>
> On Wed, Apr 15, 2020 at 8:00 AM Sebastian Huber
>  wrote:
> >
> > On 15/04/2020 15:55, Utkarsh Rai wrote:
> >
> > Yes sir.
> >
> > Ok, good, then you should do this. Maybe someone else solved this
> problem already.
> >
> >
> > On Wed 15 Apr, 2020, 7:21 PM Sebastian Huber, <
> sebastian.hu...@embedded-brains.de> wrote:
> >>
> >> On 15/04/2020 15:00, Utkarsh Rai wrote:
> >>
> >> > Okay, so from what I could gather the time between the two gettime
> >> > calls can exceed 1 sec if it is preempted by another process in
> >> > between. Is my line of thought correct?
> >> There is no other process. What you want to know is if the difference
> >> between two struct timespec is greater than or equal to 1ns, right?
> >
> > ___
> > 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

fdt_rw.c: Unchecked return value (CID #1047324) (#3947)

[Utkarsh Rai]

As is suggested in the ticket  I
checked for return value checking in the upstream and it is not present.
Should I send a patch that checks for the error value (FDT_END)?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Utkarsh Rai]

Rationale for a new test-

>Although most of the test cases for this test have been taken from 
>clockrealtime,
adding it to the current test with CLOCK_MONOTONIC may break the existing cases.

>This test has a new case which tests for no change of delay with monotonic 
>clock when
the realtime clock has been modified, this is easier to add in a new test.
---
 testsuites/psxtests/Makefile.am   |  10 +
 testsuites/psxtests/configure.ac  |   1 +
 testsuites/psxtests/psxclocknanosleep/init.c  | 182 ++
 .../psxclocknanosleep/psxclocknanosleep.doc   |  15 ++
 .../psxclocknanosleep/psxclocknanosleep.scn   |  14 ++
 5 files changed, 222 insertions(+)
 create mode 100644 testsuites/psxtests/psxclocknanosleep/init.c
 create mode 100644 testsuites/psxtests/psxclocknanosleep/psxclocknanosleep.doc
 create mode 100644 testsuites/psxtests/psxclocknanosleep/psxclocknanosleep.scn

diff --git a/testsuites/psxtests/Makefile.am b/testsuites/psxtests/Makefile.am
index 1f9e4233ec..ad6e41b400 100755
--- a/testsuites/psxtests/Makefile.am
+++ b/testsuites/psxtests/Makefile.am
@@ -312,6 +312,16 @@ psxclock01_CPPFLAGS = $(AM_CPPFLAGS) 
$(TEST_FLAGS_psxclock01) \
$(support_includes) -I$(top_srcdir)/include
 endif
 
+
+if TEST_psxclocknanosleep
+psx_tests += psxclocknanosleep
+psx_screens += psxclocknanosleep/psxclocknanosleep.scn
+psx_docs += psxclockrealtime01/psxclocknanosleep.doc
+psxclocknanosleep_SOURCES = psxclocknanosleep/init.c
+psxclocknanosleep_CPPFLAGS = $(AM_CPPFLAGS) \
+   $(TEST_FLAGS_psxclocknanosleep) $(support_includes)
+endif
+
 if TEST_psxclockrealtime01
 psx_tests += psxclockrealtime01
 psx_screens += psxclockrealtime01/psxclockrealtime01.scn
diff --git a/testsuites/psxtests/configure.ac b/testsuites/psxtests/configure.ac
index 139787cccb..52b5e1624b 100644
--- a/testsuites/psxtests/configure.ac
+++ b/testsuites/psxtests/configure.ac
@@ -75,6 +75,7 @@ RTEMS_TEST_CHECK([psxcleanup01])
 RTEMS_TEST_CHECK([psxcleanup02])
 RTEMS_TEST_CHECK([psxclock])
 RTEMS_TEST_CHECK([psxclock01])
+RTEMS_TEST_CHECK([psxclocknanosleep])
 RTEMS_TEST_CHECK([psxclockrealtime01])
 RTEMS_TEST_CHECK([psxconcurrency01])
 RTEMS_TEST_CHECK([psxcond01])
diff --git a/testsuites/psxtests/psxclocknanosleep/init.c 
b/testsuites/psxtests/psxclocknanosleep/init.c
new file mode 100644
index 00..15e3ff396a
--- /dev/null
+++ b/testsuites/psxtests/psxclocknanosleep/init.c
@@ -0,0 +1,182 @@
+/*
+ *  Copyright (c) 2020 Utkarsh Rai.
+ *
+ *  The license and distribution terms for this file may be
+ *  found in the file LICENSE in this distribution or at
+ *  http://www.rtems.org/license/LICENSE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static void assert_eno(const char *hint, int eno, int expected_eno)
+{
+  const char *warn;
+
+  if (eno != expected_eno) {
+warn = "WARNING: ";
+  } else {
+warn = "";
+  }
+
+  printf(
+"%s%s: actual '%s', expected '%s'\n",
+warn,
+hint,
+strerror(eno),
+strerror(expected_eno)
+  );
+
+  rtems_test_assert( eno == expected_eno );
+}
+
+
+static void assert_rv(const char *hint, int rv, int expected_eno)
+{
+  int eno;
+
+  if (rv != 0) {
+eno = EINVAL;
+  } else {
+eno = 0;
+  }
+
+  assert_eno(hint, eno, expected_eno);
+}
+
+typedef enum {
+  MODE_TIMEOUT_FINITE,
+  MODE_TIMEOUT_NEGATIVE_SEC,
+  MODE_TIMEOUT_NEGATIVE_NSEC,
+  MODE_TIMEOUT_NEGATIVE_SEC_NSEC,
+  MODE_TIMEOUT_HUGE_NSEC,
+  MODE_TIMEOUT_CLOCK_MODIFY
+} test_mode;
+
+static void run(test_mode mode, const char* test_name)
+{
+ struct timespec  delay_time;
+ struct timespec  configure_time;
+ int rv;
+ int expected_eno;
+
+ switch (mode) {
+ case MODE_TIMEOUT_FINITE:
+   rv = clock_gettime( CLOCK_MONOTONIC, &delay_time );
+   rtems_test_assert( rv == 0 );
+
+   delay_time.tv_sec += 1;
+   delay_time.tv_nsec += 1;
+   expected_eno = ETIMEDOUT;
+   break;
+ case MODE_TIMEOUT_HUGE_NSEC:
+   delay_time.tv_sec = 1;
+   delay_time.tv_nsec = LONG_MAX;
+   expected_eno = EINVAL;
+   break;
+ case MODE_TIMEOUT_NEGATIVE_NSEC:
+   delay_time.tv_sec = 1;
+   delay_time.tv_nsec = -1;
+   expected_eno = EINVAL;
+   break;
+ case MODE_TIMEOUT_NEGATIVE_SEC_NSEC:
+   delay_time.tv_sec = -1;
+   delay_time.tv_nsec = -1;
+   expected_eno = EINVAL;
+   break;
+ case MODE_TIMEOUT_NEGATIVE_SEC:
+   delay_time.tv_sec = -1;
+   delay_time.tv_nsec = 1;
+   expected_eno = ETIMEDOUT;
+   break;
+ case MODE_TIMEOUT_CLOCK_MODIFY:
+   rv = clock_gettime( CLOCK_REALTIME, &configure_time );
+   rtems_test_assert( rv == 0 );
+
+   configure_time.tv_sec += INT64_MAX;
+
+   rv = clock_settime( CLOCK_REALTIME, &configure_time );
+   rtems_test_assert( rv == 0 );
+
+   rv = clock_gettime( CLOCK_MONOTONIC, &delay_time );
+   rtems_test_assert( rv == 0 );
+
+   delay_time.tv_sec += 1;
+   delay_time.tv_nsec += 1;
+   expected_eno 

[PATCH v2] Test for clock_nanosleep() with CLOCK_MONOTONIC option.

[Utkarsh Rai]

Rationale for a new test-

>Although most of the test cases for this test have been taken from 
>clockrealtime,
adding it to the current test with CLOCK_MONOTONIC may break the existing cases.

>This test has a new case which tests for no change of delay with monotonic 
>clock when
the realtime clock has been modified, this is easier to add in a new test.
---
 testsuites/psxtests/Makefile.am   |  10 ++
 testsuites/psxtests/configure.ac  |   1 +
 .../psxtests/psxclocknanosleep01/init.c   | 155 ++
 .../psxclocknanosleep01.doc   |  15 ++
 .../psxclocknanosleep01.scn   |  14 ++
 5 files changed, 195 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..ba79804be7 100755
--- a/testsuites/psxtests/Makefile.am
+++ b/testsuites/psxtests/Makefile.am
@@ -312,6 +312,16 @@ psxclock01_CPPFLAGS = $(AM_CPPFLAGS) 
$(TEST_FLAGS_psxclock01) \
$(support_includes) -I$(top_srcdir)/include
 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_psxclockrealtime01
 psx_tests += psxclockrealtime01
 psx_screens += psxclockrealtime01/psxclockrealtime01.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_TEST_CHECK([psxcleanup02])
 RTEMS_TEST_CHECK([psxclock])
 RTEMS_TEST_CHECK([psxclock01])
+RTEMS_TEST_CHECK([psxclocknanosleep01])
 RTEMS_TEST_CHECK([psxclockrealtime01])
 RTEMS_TEST_CHECK([psxconcurrency01])
 RTEMS_TEST_CHECK([psxcond01])
diff --git a/testsuites/psxtests/psxclocknanosleep01/init.c 
b/testsuites/psxtests/psxclocknanosleep01/init.c
new file mode 100644
index 00..c1f10b9eb9
--- /dev/null
+++ b/testsuites/psxtests/psxclocknanosleep01/init.c
@@ -0,0 +1,155 @@
+/*
+ *  Copyright (c) 2020 Utkarsh Rai.
+ *
+ *  The license and distribution terms for this file may be
+ *  found in the file LICENSE in this distribution or at
+ *  http://www.rtems.org/license/LICENSE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+typedef enum {
+  MODE_TIMEOUT_FINITE,
+  MODE_TIMEOUT_NEGATIVE_SEC,
+  MODE_TIMEOUT_NEGATIVE_NSEC,
+  MODE_TIMEOUT_NEGATIVE_SEC_NSEC,
+  MODE_TIMEOUT_HUGE_NSEC,
+  MODE_TIMEOUT_CLOCK_MODIFY
+} test_mode;
+
+static void assert_eno(const char *hint, int eno, int expected_eno)
+{
+  const char *warn = "";
+
+  if ( eno != expected_eno ) {
+warn = "WARNING: ";
+  }
+
+  printf(
+"%s%s: actual '%s', expected '%s'\n",
+warn,
+hint,
+strerror(eno),
+strerror(expected_eno)
+  );
+
+  rtems_test_assert( eno == expected_eno );
+}
+
+
+static void assert_rv(const char *hint, int rv, int expected_eno)
+{
+  int eno;
+
+  if ( rv != 0 ) {
+eno = EINVAL;
+  } else {
+eno = 0;
+  }
+
+  assert_eno( hint, eno, expected_eno );
+}
+
+static void run(test_mode mode, const char* test_name)
+{
+ struct timespec  delay_time;
+ struct timespec  configure_time;
+ int rv;
+ int expected_eno;
+
+ printf("***%s*\n", test_name);
+
+ switch (mode) {
+   case MODE_TIMEOUT_FINITE:
+ rv = clock_gettime( CLOCK_MONOTONIC, &delay_time );
+ rtems_test_assert( rv == 0 );
+
+ delay_time.tv_sec += 1;
+ delay_time.tv_nsec += 1;
+ expected_eno = ETIMEDOUT;
+ break;
+
+   case MODE_TIMEOUT_HUGE_NSEC:
+ delay_time.tv_sec = 1;
+ delay_time.tv_nsec = LONG_MAX;
+ expected_eno = EINVAL;
+ break;
+
+   case MODE_TIMEOUT_NEGATIVE_NSEC:
+ delay_time.tv_sec = 1;
+ delay_time.tv_nsec = -1;
+ expected_eno = EINVAL;
+ break;
+
+   case MODE_TIMEOUT_NEGATIVE_SEC_NSEC:
+ delay_time.tv_sec = -1;
+ delay_time.tv_nsec = -1;
+ expected_eno = EINVAL;
+ break;
+
+   case MODE_TIMEOUT_NEGATIVE_SEC:
+ delay_time.tv_sec = -1;
+ delay_time.tv_nsec = 1;
+ expected_eno = ETIMEDOUT;
+ break;
+
+   case MODE_TIMEOUT_CLOCK_MODIFY:
+ rv = clock_gettime( CLOCK_REALTIME, &configure_time );
+ rtems_test_assert( rv == 0 );
+
+ configure_time.tv_sec += 3600;
+ rv = clock_settime( CLOCK_REALTIME, &configure_time );
+ rtems_test_assert( rv == 0 );
+
+ rv = clock_gettime(

Test for clock_nanosleep

[Utkarsh Rai]

I have written the following patch based on the new test framework.
Although the test runs successfully, I am not sure I have utilized the
RTEMS_LINKER_ROSET/ ROSET_DECLARE properly to link test objects.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Utkarsh Rai]

>This test is based on the new test framework and has been tested for the 
>sparc/erc32 bsp.
---
 testsuites/psxtests/Makefile.am   |  10 ++
 testsuites/psxtests/configure.ac  |   1 +
 .../psxtests/psxclocknanosleep01/init.c   | 102 +++
 .../psxclocknanosleep01.doc   |  13 ++
 .../psxclocknanosleep01.scn   |  39 ++
 .../test-clock-nanosleep.c| 119 ++
 6 files changed, 284 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
 create mode 100644 
testsuites/psxtests/psxclocknanosleep01/test-clock-nanosleep.c

diff --git a/testsuites/psxtests/Makefile.am b/testsuites/psxtests/Makefile.am
index 1f9e4233ec..89bf493c47 100755
--- a/testsuites/psxtests/Makefile.am
+++ b/testsuites/psxtests/Makefile.am
@@ -312,6 +312,16 @@ psxclock01_CPPFLAGS = $(AM_CPPFLAGS) 
$(TEST_FLAGS_psxclock01) \
$(support_includes) -I$(top_srcdir)/include
 endif
 
+if TEST_psxclocknanosleep01
+psx_tests += psxclocknanosleep01
+psx_screens += psxclocknanosleep01/psxclocknanosleep01.scn
+psx_docs += psxclocknanosleep01/psxclocknanosleep01.doc
+psxclocknanosleep01_SOURCES = psxclocknanosleep01/init.c
+psxclocknanosleep01_SOURCES += psxclocknanosleep01/test-clock-nanosleep.c
+psxclocknanosleep01_CPPFLAGS = $(AM_CPPFLAGS) 
$(TEST_FLAGS_psxclocknanosleep01) \
+   $(support_includes) -I$(top_srcdir)/include
+endif
+
 if TEST_psxclockrealtime01
 psx_tests += psxclockrealtime01
 psx_screens += psxclockrealtime01/psxclockrealtime01.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_TEST_CHECK([psxcleanup02])
 RTEMS_TEST_CHECK([psxclock])
 RTEMS_TEST_CHECK([psxclock01])
+RTEMS_TEST_CHECK([psxclocknanosleep01])
 RTEMS_TEST_CHECK([psxclockrealtime01])
 RTEMS_TEST_CHECK([psxconcurrency01])
 RTEMS_TEST_CHECK([psxcond01])
diff --git a/testsuites/psxtests/psxclocknanosleep01/init.c 
b/testsuites/psxtests/psxclocknanosleep01/init.c
new file mode 100644
index 00..420c33b648
--- /dev/null
+++ b/testsuites/psxtests/psxclocknanosleep01/init.c
@@ -0,0 +1,102 @@
+/* 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 
+
+const char rtems_test_name[] = "PSXCLOCKNANOSLEEP01";
+
+static char buffer[512];
+
+RTEMS_LINKER_ROSET_DECLARE(t_clock_nanosleep, const char *);
+RTEMS_LINKER_ROSET(t_clock_nanosleep, const char *);
+
+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),
+

Memory Protection project interface details (GSoC 2020)

[Utkarsh Rai]

Hello,
This is to ensure that all the interested parties are on the same page
before I start my project and can give their invaluable feedback.
My GSoC project, providing user-configurable thread stack protection,
requires adding architecture-specific low-level support as well as
high-level API support. I will be starting my project with ARMv7-A (on BBB)
based MMU since RTEMS already has quite mature support for it. As already
mentioned in my proposal I will be focusing more on the High-level
interface and let it drive whatever further low-level support is needed.
Once the application uses MMU for thread stack address generation each
thread will be automatically protected as the page tables other than that
of the executing thread would be made dormant. When the user has to share
thread stacks they will have to obtain the stack attributes of the threads
to be shared by pthread_attr_getstack() and then get a file descriptor of
the memory to be mapped by a call to shm_open() and finally map this to the
stack of the other thread through
mmap(), this is the POSIX compliant way I could think of. Now at the low
level, it means mapping the page table of the thread to be shared into the
address space of the executing thread. This is an area where the low-level
support has to be provided. At the high-level, this means providing support
to mmap and shared-memory interface as mmap provides support for a file by
simply
copying the memory from the file to the destination. For shared memory
objects it can
provide read/write access but cannot provide restriction of write/read
access. One of the areas that I have to look into more detail is thread
context-switch, as after every context switch the TLBs need to be flushed
and reinitialized lest we get an invalid address for the executing thread.
Since context-switch is low-level architecture-specific, this also has to
be provided with more support.
Kindly provide your feedback if I have missed something or I have a wrong
idea about it.

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

Re: Memory Protection project interface details (GSoC 2020)

[Utkarsh Rai]

On Tue, May 12, 2020 at 9:27 AM Gedare Bloom  wrote:

> On Thu, May 7, 2020 at 9:59 PM Hesham Almatary
>  wrote:
> >
> > Hello Utkarsh,
> >
> > I'd suggest you don't spend too much efforts on setting up BBB
> > hardware if you haven't already. Debugging on QEMU with GDB is way
> > easier, and you can consider either qemu-xilinx-zynq-a9 or rpi2 BSPs.
> > Later, you can move your code to BBB if you want, since both are based
> > on ARMv7.
> +1
>
> Past work has also used psim successfully I thought? Or am I mistaken
> there.
>
> >
> > On Thu, 7 May 2020 at 18:26, Utkarsh Rai 
> wrote:
> > >
> > > Hello,
> > > This is to ensure that all the interested parties are on the same page
> before I start my project and can give their invaluable feedback.
> Excellent, thank you for getting the initiative.
>
> I'll be taking on the primary mentorship for your project, with
> support from the co-mentors (Peter, Hesham, Sebastian). For now, I
> prefer you to continue to make your presence on the mailing list. We
> will establish other forms of communication as needed and will take on
> IRC meetings once coding begins in earnest.
>
> > > My GSoC project, providing user-configurable thread stack protection,
> requires adding architecture-specific low-level support as well as
> high-level API support. I will be starting my project with ARMv7-A (on BBB)
> based MMU since RTEMS already has quite mature support for it. As already
> mentioned in my proposal I will be focusing more on the High-level
> interface and let it drive whatever further low-level support is needed.
> > > Once the application uses MMU for thread stack address generation each
> thread will be automatically protected as the page tables other than that
> of the executing thread would be made dormant. When the user has to share
> thread stacks they will have to obtain the stack attributes of the threads
> to be shared by pthread_attr_getstack() and then get a file descriptor of
> the memory to be mapped by a call to shm_open() and finally map this to the
> stack of the other thread through
> > > mmap(), this is the POSIX compliant way I could think of. Now at the
> low level, it means mapping the page table of the thread to be shared into
> the address space of the executing thread. This is an area where the
> low-level support has to be provided. At the high-level, this means
> providing support to mmap and shared-memory interface as mmap provides
> support for a file by simply
> > > copying the memory from the file to the destination. For shared memory
> objects it can
> > > provide read/write access but cannot provide restriction of write/read
> access. One of the areas that I have to look into more detail is thread
> context-switch, as after every context switch the TLBs need to be flushed
> and reinitialized lest we get an invalid address for the executing thread.
> Since context-switch is low-level architecture-specific, this also has to
> be provided with more support.
>
> This is really dense text. Try to break apart your writing a little
> bit to help clarify your thoughts.  You should also translate some of
> your proposal into a wiki page if you haven't started that yet, and a
> blog post. Both of those will help to focus your thoughts into words.
>
> "mapping the page table" is not meaningful to me. I think you mean
> something like "mapping a page from the page table"?

Will the design
> support sharing task stacks using MPUs with 4 regions? 8?  (It seems
> challenging to me, but might be possible in some limited
> configurations. Having support for those kinds of targets might still
> be useful, with the caveat that sharing stacks is not possible.)
>

I will have to look into this in a bit more detail before I can give you a
comprehensive answer.


> The first step is to get a BSP running that has sufficient
> capabilities for you to test out memory protection with. Do a little
> bit of digging, but definitely simulation is the way to go.
>

As suggested by Hesham, I have been able to run the qemu-Xilinx-zynq-a9 BSP
on qemu and I have learned how to debug it through GDB.
The BSP supports memory protection and as pointed out once I get it done on
this, I can move my code for other BSP with ARMv7 (RPI, BBB ).


> The second step from my perspective is to determine how to introduce
> strict isolation between task stacks. Don't worry about sharing at
> this stage, but rather can you completely isolate tasks? Then you can
> start to poke holes in the isolation.
>

 My understanding of this is that to completely isolate the tasks and page
tables of the task will be placed in two separate re

Re: Memory Protection project interface details (GSoC 2020)

[Utkarsh Rai]

On Wed, May 13, 2020 at 3:56 AM Joel Sherrill  wrote:

> I hate to top post but I'm not sure where to insert this.
>
> As a first step, I would ensure that paging catches stack overflow errors.
>

I understand that any thread-stack protection mechanism has to ensure
against a stack overflow error, adding this to my plan would mean that I
have to re-adjust my goals, one of them being support for typed-memory
objects. I would request your opinion as to what features are more valuable
to the community so I can focus on them.

Then move on to an optional capability where threads cannot access the
> stacks of other threads. POSIX does not say anything about whether that
> should work or not but there are cases (especially in RTEMS) where if a
> blocking thread has a message queue buffer on a stack and another thread
> does a send, then it will write to another thread's stack.
>

One of the most important parts of this project will be proper
documentation to make the user understand the possible cases where enabling
this feature will cause problems and proper handling of these issues(For
all the cases the users need stack sharing, they will have to explicitly
make certain calls to share stacks )

> This is accepted programming practice.
>


>
> I'm not opposed to an option where per-thread stack protection is
> available. But making it mandatory is a bad step. Using the MMU to detect
> stack overflow is good.
>

Yes, the thread-stack protection will be user-configurable.

>
> As Hesham mentioned, this is hard on some architectures if you don't have
> a nice page management system. Can you make sure the minimum processor
> architectural requirements are documented. Not just in an email. This will
> ultimately be information in the CPU Supplement.
>
Noted.

>
> --joel
>
> On Tue, May 12, 2020 at 5:02 PM Hesham Almatary <
> hesham.almat...@cl.cam.ac.uk> wrote:
>
>> On Tue, 12 May 2020 at 04:57, Gedare Bloom  wrote:
>> >
>> > On Thu, May 7, 2020 at 9:59 PM Hesham Almatary
>> >  wrote:
>> > >
>> > > Hello Utkarsh,
>> > >
>> > > I'd suggest you don't spend too much efforts on setting up BBB
>> > > hardware if you haven't already. Debugging on QEMU with GDB is way
>> > > easier, and you can consider either qemu-xilinx-zynq-a9 or rpi2 BSPs.
>> > > Later, you can move your code to BBB if you want, since both are based
>> > > on ARMv7.
>> > +1
>> >
>> > Past work has also used psim successfully I thought? Or am I mistaken
>> there.
>> >
>> Before my 2012 project (and part of it, yes), we used psim. The use of
>> software TLBs wasn't very ideal/easy though, so we moved to ARM in
>> 2013. The development/testing was mainly on a RPi board. I don't
>> remember there was a QEMU model for it yet.
>>
>>
>> > >
>> > > On Thu, 7 May 2020 at 18:26, Utkarsh Rai 
>> wrote:
>> > > >
>> > > > Hello,
>> > > > This is to ensure that all the interested parties are on the same
>> page before I start my project and can give their invaluable feedback.
>> > Excellent, thank you for getting the initiative.
>> >
>> > I'll be taking on the primary mentorship for your project, with
>> > support from the co-mentors (Peter, Hesham, Sebastian). For now, I
>> > prefer you to continue to make your presence on the mailing list. We
>> > will establish other forms of communication as needed and will take on
>> > IRC meetings once coding begins in earnest.
>> >
>> > > > My GSoC project, providing user-configurable thread stack
>> protection, requires adding architecture-specific low-level support as well
>> as high-level API support. I will be starting my project with ARMv7-A (on
>> BBB) based MMU since RTEMS already has quite mature support for it. As
>> already mentioned in my proposal I will be focusing more on the High-level
>> interface and let it drive whatever further low-level support is needed.
>> > > > Once the application uses MMU for thread stack address generation
>> each thread will be automatically protected as the page tables other than
>> that of the executing thread would be made dormant. When the user has to
>> share thread stacks they will have to obtain the stack attributes of the
>> threads to be shared by pthread_attr_getstack() and then get a file
>> descriptor of the memory to be mapped by a call to shm_open() and finally
>> map this to the stack of the other thread through
>> > > > mmap(), this is the POSIX compliant way I could 

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

[Utkarsh Rai]

Hello,
My GSoC project,  providing thread stack protection support, has to be a
user-configurable feature.
My question is,  what would be the best way to implement this, my idea was
to model it based on the existing system configuration
, but Dr.
Gedare pointed out that configuration is undergoing heavy changes and may
look completely different in future releases. Kindly advise me as to what
would be the best way to proceed.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Memory Protection project interface details (GSoC 2020)

[Utkarsh Rai]

On Wed, May 13, 2020 at 8:11 PM Gedare Bloom  wrote:

> On Wed, May 13, 2020 at 6:12 AM Utkarsh Rai 
> wrote:
> >
> >
> >
> > On Wed, May 13, 2020 at 3:56 AM Joel Sherrill  wrote:
> >>
> >> I hate to top post but I'm not sure where to insert this.
> >>
> >> As a first step, I would ensure that paging catches stack overflow
> errors.
> >
> >
> > I understand that any thread-stack protection mechanism has to ensure
> against a stack overflow error, adding this to my plan would mean that I
> have to re-adjust my goals, one of them being support for typed-memory
> objects. I would request your opinion as to what features are more valuable
> to the community so I can focus on them.
> >
>
> When Joel says stack overflow he means a thread writing beyond the
> thread's stack area. I don't think this would require TYM? Usually the
> way this is done is to add a gap between stacks when you allocate
> them, which is a bit wasteful of physical memory.
>
> Yes, it will not require TYM, sorry I did not make my thoughts clear.
Protection against stack overflow is necessary and independent of the TYM
interface, my concern is I do not have an estimate of the time it would
take to implement this. This means I will have to re-adjust my goals such
as the implementation of the TYM interface. If we plan on providing
protection against stack overflow I would request your opinion on how
should I re-adjust my goals so that it remains feasible for me to complete
them.

> >> Then move on to an optional capability where threads cannot access the
> stacks of other threads. POSIX does not say anything about whether that
> should work or not but there are cases (especially in RTEMS) where if a
> blocking thread has a message queue buffer on a stack and another thread
> does a send, then it will write to another thread's stack.
> >
> >
> > One of the most important parts of this project will be proper
> documentation to make the user understand the possible cases where enabling
> this feature will cause problems and proper handling of these issues(For
> all the cases the users need stack sharing, they will have to explicitly
> make certain calls to share stacks )
> >>
> >> This is accepted programming practice.
> >
> >
> >>
> >>
> >> I'm not opposed to an option where per-thread stack protection is
> available. But making it mandatory is a bad step. Using the MMU to detect
> stack overflow is good.
> >
> >
> > Yes, the thread-stack protection will be user-configurable.
> >>
> >>
> >> As Hesham mentioned, this is hard on some architectures if you don't
> have a nice page management system. Can you make sure the minimum processor
> architectural requirements are documented. Not just in an email. This will
> ultimately be information in the CPU Supplement.
> >
> > Noted.
> >>
> >>
> >> --joel
> >>
> >> On Tue, May 12, 2020 at 5:02 PM Hesham Almatary <
> hesham.almat...@cl.cam.ac.uk> wrote:
> >>>
> >>> On Tue, 12 May 2020 at 04:57, Gedare Bloom  wrote:
> >>> >
> >>> > On Thu, May 7, 2020 at 9:59 PM Hesham Almatary
> >>> >  wrote:
> >>> > >
> >>> > > Hello Utkarsh,
> >>> > >
> >>> > > I'd suggest you don't spend too much efforts on setting up BBB
> >>> > > hardware if you haven't already. Debugging on QEMU with GDB is way
> >>> > > easier, and you can consider either qemu-xilinx-zynq-a9 or rpi2
> BSPs.
> >>> > > Later, you can move your code to BBB if you want, since both are
> based
> >>> > > on ARMv7.
> >>> > +1
> >>> >
> >>> > Past work has also used psim successfully I thought? Or am I
> mistaken there.
> >>> >
> >>> Before my 2012 project (and part of it, yes), we used psim. The use of
> >>> software TLBs wasn't very ideal/easy though, so we moved to ARM in
> >>> 2013. The development/testing was mainly on a RPi board. I don't
> >>> remember there was a QEMU model for it yet.
> >>>
> >>>
> >>> > >
> >>> > > On Thu, 7 May 2020 at 18:26, Utkarsh Rai 
> wrote:
> >>> > > >
> >>> > > > Hello,
> >>> > > > This is to ensure that all the interested parties are on the
> same page before I start my project and can give their invaluable feedback.
> >>> > Excellent, thank yo

Re: Memory Protection project interface details (GSoC 2020)

[Utkarsh Rai]

On Wed, May 13, 2020 at 10:27 PM Joel Sherrill  wrote:

>
>
> On Wed, May 13, 2020 at 9:41 AM Gedare Bloom  wrote:
>
>> On Wed, May 13, 2020 at 6:12 AM Utkarsh Rai 
>> wrote:
>> >
>> >
>> >
>> > On Wed, May 13, 2020 at 3:56 AM Joel Sherrill  wrote:
>> >>
>> >> I hate to top post but I'm not sure where to insert this.
>> >>
>> >> As a first step, I would ensure that paging catches stack overflow
>> errors.
>> >
>> >
>> > I understand that any thread-stack protection mechanism has to ensure
>> against a stack overflow error, adding this to my plan would mean that I
>> have to re-adjust my goals, one of them being support for typed-memory
>> objects. I would request your opinion as to what features are more valuable
>> to the community so I can focus on them.
>> >
>>
>> When Joel says stack overflow he means a thread writing beyond the
>> thread's stack area. I don't think this would require TYM? Usually the
>> way this is done is to add a gap between stacks when you allocate
>> them, which is a bit wasteful of physical memory.
>>
>
> A gap in the virtual address?  I guess if you map virtual:physical 1:1,
> then it is a gap in both. But technically, it doesn't have to be 1:1.
>
> Independent of being pedantic on that, enlighten me how using the MMU
> for stack overflow protection isn't a logical step on the path of this
> project?
> It is just a mapping thread stacks and letting every thread have access to
> all threads memory but leaving gaps.
>
> I have seen the basic benefits of an MMU as follows (increasing in
> complexity and dynamicism):
>
> + mark region of memory as read/write, execute, read only, no cache,
>and for stack use only. What you can do depends on the architecture.
>   This is a gross form of memory protection using large areas of memory.
>This is usually done at BSP startup and left along.
>
> + Provide each thread a protected area where overflow/underflow is
>   detected by the MMU. This requires finer grain control but if still
> simple
>since it is only changed at run-time by the thread stack
> allocator/deallocator.
>
> + Finer grain control of which threads can access which other threads'
> stack.
>This will require more management and something happens at context
> switch.
>
> + Very fine grain control of objects like CHERI and other similar
> approaches.
>
> This project is aiming for the third. Wouldn't it need to move through the
> first
> two capabilities?
>

Thank you, the stack-overflow protection should be the first obvious step
when implementing this feature, your analysis has helped me clear my
doubts.

>
>
>>
>> >> Then move on to an optional capability where threads cannot access the
>> stacks of other threads. POSIX does not say anything about whether that
>> should work or not but there are cases (especially in RTEMS) where if a
>> blocking thread has a message queue buffer on a stack and another thread
>> does a send, then it will write to another thread's stack.
>> >
>> >
>> > One of the most important parts of this project will be proper
>> documentation to make the user understand the possible cases where enabling
>> this feature will cause problems and proper handling of these issues(For
>> all the cases the users need stack sharing, they will have to explicitly
>> make certain calls to share stacks )
>> >>
>> >> This is accepted programming practice.
>> >
>> >
>> >>
>> >>
>> >> I'm not opposed to an option where per-thread stack protection is
>> available. But making it mandatory is a bad step. Using the MMU to detect
>> stack overflow is good.
>> >
>> >
>> > Yes, the thread-stack protection will be user-configurable.
>> >>
>> >>
>> >> As Hesham mentioned, this is hard on some architectures if you don't
>> have a nice page management system. Can you make sure the minimum processor
>> architectural requirements are documented. Not just in an email. This will
>> ultimately be information in the CPU Supplement.
>> >
>> > Noted.
>> >>
>> >>
>> >> --joel
>> >>
>> >> On Tue, May 12, 2020 at 5:02 PM Hesham Almatary <
>> hesham.almat...@cl.cam.ac.uk> wrote:
>> >>>
>> >>> On Tue, 12 May 2020 at 04:57, Gedare Bloom  wrote:
>> >>> >
>> >>> > On Thu, May 7, 2020 at 9:59 PM Hesh

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

[Utkarsh Rai]

On Thu, May 14, 2020 at 10:23 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Utkarsh Rai,
>
> On 13/05/2020 14:30, Utkarsh Rai wrote:
> > Hello,
> > My GSoC project,  providing thread stack protection support, has to be
> > a user-configurable feature.
> > My question is,  what would be the best way to implement this, my idea
> > was to model it based on the existing system configuration
> > <https://docs.rtems.org/branches/master/c-user/config/intro.html>, but
> > Dr. Gedare pointed out that configuration is undergoing heavy changes
> > and may look completely different in future releases. Kindly advise me
> > as to what would be the best way to proceed.
> before we start with an implementation. It would be good to define what
> a thread stack protection support is supposed to do.


The thread stack protection mechanism will protect against stack overflow
errors and will completely isolate the thread stacks from each other.
Sharing of thread stack will be possible only when the user makes explicit
calls to do so. More details about this can be found in this thread
<https://lists.rtems.org/pipermail/devel/2020-May/059768.html>.

> Then there should
> be a concept for systems with a Memory Protection Unit (MPU) and a
> concept for systems with a Memory Management Unit (MMU). MMUs may
> provide normal 4KiB Pages, large Pages (for example 1MiB) or something
> more flexible. We should identify BSPs which should have support for
> this. For each BSP should be a concept. Then we should think about how a
> user can configure this feature.

For memory protection will have a 1:1 VA-PA address translation that means
> a 4KiB page size will be set for both the MPU and MMU, a 1:1 mapping will
> ensure we will have to do lesser page table walks.This would although mean
> that we would have page tables of  1MB. I will be first providing the
> support for Armv7 based BSPs (RPi , BBB, etc. have MMU support) then when I
> have a working example I will move on to provide the support for RISC-V.
> which has MPU support.
___
devel mailing list
devel@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 Sat, May 16, 2020 at 9:16 PM Joel Sherrill  wrote:

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

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


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

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


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

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

[Utkarsh Rai]

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

> On Mon, May 18, 2020 at 4:31 AM Utkarsh Rai 
> wrote:
> >
> >
> >
> >
> > On Sat, May 16, 2020 at 9:16 PM Joel Sherrill  wrote:
> >>
> >>
> >>
> >> On Sat, May 16, 2020 at 10:14 AM Gedare Bloom  wrote:
> >>>
> >>> Utkarsh,
> >>>
> >>> What do you mean by "This would although mean that we would have page
> tables of  1MB."
> >>>
> >>> Check that you use plain text when inlining a reply, or at least that
> you broke the reply format.
> >>>
> >>> Gedare
> >>>
> >>> On Fri, May 15, 2020, 6:04 PM Utkarsh Rai 
> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On Thu, May 14, 2020 at 10:23 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> >>>>>
> >>>>> Hello Utkarsh Rai,
> >>>>>
> >>>>> On 13/05/2020 14:30, Utkarsh Rai wrote:
> >>>>> > Hello,
> >>>>> > My GSoC project,  providing thread stack protection support, has
> to be
> >>>>> > a user-configurable feature.
> >>>>> > My question is,  what would be the best way to implement this, my
> idea
> >>>>> > was to model it based on the existing system configuration
> >>>>> > <https://docs.rtems.org/branches/master/c-user/config/intro.html>,
> but
> >>>>> > Dr. Gedare pointed out that configuration is undergoing heavy
> changes
> >>>>> > and may look completely different in future releases. Kindly
> advise me
> >>>>> > as to what would be the best way to proceed.
> >>>>> before we start with an implementation. It would be good to define
> what
> >>>>> a thread stack protection support is supposed to do.
> >>>>
> >>>>
> >>>> The thread stack protection mechanism will protect against stack
> overflow errors and will completely isolate the thread stacks from each
> other. Sharing of thread stack will be possible only when the user makes
> explicit calls to do so. More details about this can be found in this
> thread.
> >>>>>
> >>>>> Then there should
> >>>>> be a concept for systems with a Memory Protection Unit (MPU) and a
> >>>>> concept for systems with a Memory Management Unit (MMU). MMUs may
> >>>>> provide normal 4KiB Pages, large Pages (for example 1MiB) or
> something
> >>>>> more flexible. We should identify BSPs which should have support for
> >>>>> this. For each BSP should be a concept. Then we should think about
> how a
> >>>>> user can configure this feature.
> >>>>>
> >>>>> For memory protection will have a 1:1 VA-PA address translation that
> means a 4KiB page size will be set for both the MPU and MMU, a 1:1 mapping
> will ensure we will have to do lesser page table walks.This would although
> mean that we would have page tables of  1MB. I will be first providing the
> support for Armv7 based BSPs (RPi , BBB, etc. have MMU support) then when I
> have a working example I will move on to provide the support for RISC-V.
> which has MPU support.
> >>
> >>
> >> I think Sebastian is asking exactly what I did. What are the processor
> (specific CPU) requirements to support thread stack protection?
> >
> >
> > For thread stack protection the processor should have the option of
> paging along with appropriate 'access bits' setting. Both RISC-V and
> ARMv7-A (the ones that I will be focusing on my project) have the option of
> defining pages of 4KiB size with appropriate access bits.
> >
> >>
> >>
> >> For example, to be effective, I imagine a 1MB granularity might be
> sufficient to protect code versus data/bss. But it is likely insufficient
> to protect thread stacks.
> >>
> >> Similarly, a processor with a limited number of "protection areas"
> would be unsuitable as a basis for implementing thread stack protection.
> Here I am thinking of the PowerPC with a handful of TLB registers. You
> would have to turn on paging.
> >
> >
> > I agree, most of the processors have protection regions between 8 to 16
> and in some cases as less as 4. For stack protection paging with each page
> of size 4KiB, as it is applicable for processors with mpu or mmu and is
> optimal, in the sense that we woul

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

[Utkarsh Rai]

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

> On Tue, 19 May 2020 at 14:00, Utkarsh Rai  wrote:
> >
> >
> >
> > On Mon, May 18, 2020 at 8:38 PM Gedare Bloom  wrote:
> >>
> >> On Mon, May 18, 2020 at 4:31 AM Utkarsh Rai 
> wrote:
> >> >
> >> >
> >> >
> >> >
> >> > On Sat, May 16, 2020 at 9:16 PM Joel Sherrill  wrote:
> >> >>
> >> >>
> >> >>
> >> >> On Sat, May 16, 2020 at 10:14 AM Gedare Bloom 
> wrote:
> >> >>>
> >> >>> Utkarsh,
> >> >>>
> >> >>> What do you mean by "This would although mean that we would have
> page tables of  1MB."
> >> >>>
> >> >>> Check that you use plain text when inlining a reply, or at least
> that you broke the reply format.
> >> >>>
> >> >>> Gedare
> >> >>>
> >> >>> On Fri, May 15, 2020, 6:04 PM Utkarsh Rai 
> wrote:
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> On Thu, May 14, 2020 at 10:23 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> >> >>>>>
> >> >>>>> Hello Utkarsh Rai,
> >> >>>>>
> >> >>>>> On 13/05/2020 14:30, Utkarsh Rai wrote:
> >> >>>>> > Hello,
> >> >>>>> > My GSoC project,  providing thread stack protection support,
> has to be
> >> >>>>> > a user-configurable feature.
> >> >>>>> > My question is,  what would be the best way to implement this,
> my idea
> >> >>>>> > was to model it based on the existing system configuration
> >> >>>>> > <
> https://docs.rtems.org/branches/master/c-user/config/intro.html>, but
> >> >>>>> > Dr. Gedare pointed out that configuration is undergoing heavy
> changes
> >> >>>>> > and may look completely different in future releases. Kindly
> advise me
> >> >>>>> > as to what would be the best way to proceed.
> >> >>>>> before we start with an implementation. It would be good to
> define what
> >> >>>>> a thread stack protection support is supposed to do.
> >> >>>>
> >> >>>>
> >> >>>> The thread stack protection mechanism will protect against stack
> overflow errors and will completely isolate the thread stacks from each
> other. Sharing of thread stack will be possible only when the user makes
> explicit calls to do so. More details about this can be found in this
> thread.
> >> >>>>>
> >> >>>>> Then there should
> >> >>>>> be a concept for systems with a Memory Protection Unit (MPU) and a
> >> >>>>> concept for systems with a Memory Management Unit (MMU). MMUs may
> >> >>>>> provide normal 4KiB Pages, large Pages (for example 1MiB) or
> something
> >> >>>>> more flexible. We should identify BSPs which should have support
> for
> >> >>>>> this. For each BSP should be a concept. Then we should think
> about how a
> >> >>>>> user can configure this feature.
> >> >>>>>
> >> >>>>> For memory protection will have a 1:1 VA-PA address translation
> that means a 4KiB page size will be set for both the MPU and MMU, a 1:1
> mapping will ensure we will have to do lesser page table walks.This would
> although mean that we would have page tables of  1MB. I will be first
> providing the support for Armv7 based BSPs (RPi , BBB, etc. have MMU
> support) then when I have a working example I will move on to provide the
> support for RISC-V. which has MPU support.
> >> >>
> >> >>
> >> >> I think Sebastian is asking exactly what I did. What are the
> processor (specific CPU) requirements to support thread stack protection?
> >> >
> >> >
> >> > For thread stack protection the processor should have the option of
> paging along with appropriate 'access bits' setting. Both RISC-V and
> ARMv7-A (the ones that I will be focusing on my project) have the option of
> defining pages of 4KiB size with appropriate access bits.
> >> >
> >> >>
> >> >>
> >> >> For example, to be effective, I

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

[Utkarsh Rai]

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

> Yes, I completely agree with Gedare, and my reply doesn't entail
> otherwise. As Gedare stated a few requirements:
>
> "2. The basic protection isolates the text, rodata, and rwdata from
> each other. There is no notion of task-specific protection domains,
> and tasks should not incur any additional overhead due to this
> protection."
>
> Such areas are the ones I meant to be "Global." The design and
> implementation should aim to make them stick in the TLB and don't get
> kicked out. Those aren't being assigned an ASID as they are global and
> won't need to get flushed and their mappings/attributes won't change.
>
> "3. The advanced protection strongly isolates all tasks' stacks.
> Sharing is done explicitly via POSIX/RTEMS APIs, and the heap and
> executive (kernel/RTEMS) memory are globally shared. A task shall only
> incur additional overhead in context switches and the first access to
> a protected region (other task's stack it shares) after a context
> switch."
>
> The additional overhead here is the flushing of the protected region
> (that might be a shared protected stack for example). Only that
> region's TLB entry will differ between tasks on context switches, and
> if ASID is used, the hardware will make sure it gets the correct entry
> (by doing a HW page-table walk).
>
> On Wed, 20 May 2020 at 11:05, Utkarsh Rai  wrote:
> >
> >
> >
> >
> > On Wed, May 20, 2020 at 7:40 AM Hesham Almatary <
> heshamelmat...@gmail.com> wrote:
> >>
> >> On Tue, 19 May 2020 at 14:00, Utkarsh Rai 
> wrote:
> >> >
> >> >
> >> >
> >> > On Mon, May 18, 2020 at 8:38 PM Gedare Bloom 
> wrote:
> >> >>
> >> >> On Mon, May 18, 2020 at 4:31 AM Utkarsh Rai 
> wrote:
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Sat, May 16, 2020 at 9:16 PM Joel Sherrill 
> wrote:
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> On Sat, May 16, 2020 at 10:14 AM Gedare Bloom 
> wrote:
> >> >> >>>
> >> >> >>> Utkarsh,
> >> >> >>>
> >> >> >>> What do you mean by "This would although mean that we would have
> page tables of  1MB."
> >> >> >>>
> >> >> >>> Check that you use plain text when inlining a reply, or at least
> that you broke the reply format.
> >> >> >>>
> >> >> >>> Gedare
> >> >> >>>
> >> >> >>> On Fri, May 15, 2020, 6:04 PM Utkarsh Rai <
> utkarsh.ra...@gmail.com> wrote:
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> On Thu, May 14, 2020 at 10:23 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> >> >> >>>>>
> >> >> >>>>> Hello Utkarsh Rai,
> >> >> >>>>>
> >> >> >>>>> On 13/05/2020 14:30, Utkarsh Rai wrote:
> >> >> >>>>> > Hello,
> >> >> >>>>> > My GSoC project,  providing thread stack protection support,
> has to be
> >> >> >>>>> > a user-configurable feature.
> >> >> >>>>> > My question is,  what would be the best way to implement
> this, my idea
> >> >> >>>>> > was to model it based on the existing system configuration
> >> >> >>>>> > <
> https://docs.rtems.org/branches/master/c-user/config/intro.html>, but
> >> >> >>>>> > Dr. Gedare pointed out that configuration is undergoing
> heavy changes
> >> >> >>>>> > and may look completely different in future releases. Kindly
> advise me
> >> >> >>>>> > as to what would be the best way to proceed.
> >> >> >>>>> before we start with an implementation. It would be good to
> define what
> >> >> >>>>> a thread stack protection support is supposed to do.
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> The thread stack protection mechanism will protect against
> stack overflow errors and will completely iso

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

[Utkarsh Rai]

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

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

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

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

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


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

We also need to consider the cases where 

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

[Utkarsh Rai]

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

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

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

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

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

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

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

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

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

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

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

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/

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

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

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 an

[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 b/bsps/shared

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

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

[PATCH v2] Strict thread-stack isolation

[Utkarsh Rai]

value 
+   * to avoid compiler warniing. 
+  */
+  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

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 -

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

value 
+   * to avoid compiler warniing. 
+  */
+  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

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_

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

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

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

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

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

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 = &ttb[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: 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 = &ttb[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

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

[Utkarsh Rai]

a/cpukit/include/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
+ */
+typ

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

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

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

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]

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

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

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: [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])
>>> > >   RTEM

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

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