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

2020-05-20 Thread Hesham Almatary 
Yes, I completely agree with Gedare, and my reply doesn't entail
otherwise. As Gedare stated a few requirements:

"2. The basic protection isolates the text, rodata, and rwdata from
each other. There is no notion of task-specific protection domains,
and tasks should not incur any additional overhead due to this
protection."

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

"3. The advanced protection strongly isolates all tasks' stacks.
Sharing is done explicitly via POSIX/RTEMS APIs, and the heap and
executive (kernel/RTEMS) memory are globally shared. A task shall only
incur additional overhead in context switches and the first access to
a protected region (other task's stack it shares) after a context
switch."

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

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

Re: [rtems/rsb]: Adding PTP support to RSB [GSoC 2020]

2020-05-20 Thread Mritunjay Sharma 
On Wed, May 20, 2020 at 1:46 AM Vijay Kumar Banerjee 
wrote:

> On Wed, May 20, 2020 at 1:27 AM Mritunjay Sharma
>  wrote:
> >
> >> Thanks for the log files. From a quick look, there is one obvious
> >> error, the linker can't find libbsd most probably because it is not
> >> there. So, you need to remove the -lbsd option from ptpd-2-1.cfg file
> >> LIBS value. Another thing to be noted is that there are a few errors
> >> due to failed version checking of the sparc-rtems5-gcc, this can
> >> probably ignored for now if removing the -lbsd option fixes your
> >> issue.
> >>
> > Thank you so much! Removing the lbsd from cfg file resloved the earlier
> > compiler issue but now another error is coming up and it is somewhat
> like this:
> >  "Makefile:502: recipe for target 'all-recursive' failed
> > make[1]: Leaving directory
> '/home/mritunjay/development/rtems/rsb/rtems/build/ptpd-2.3.1-sparc-rtems5-1/build-cxc'
> > make[1]: *** [all-recursive] Error 1
> > Makefile:412: recipe for target 'all' failed
> > make: *** [all] Error 2
> > shell cmd failed: /bin/sh -ex
> /home/mritunjay/development/rtems/rsb/rtems/build/ptpd-2.3.1-sparc-rtems5-1/do-build
> > error: building ptpd-2.3.1-sparc-rtems5-1"
> >
>
> The error is generally at the end of the log file. In this case, it is:
> ```
>
> In file included from ../../ptpd-2.3.1/src/arith.c:53:0:
> ../../ptpd-2.3.1/src/ptpd.h:93:10: fatal error: netinet/ip.h: No such
> file or directory
>  #include 
>   ^~
> compilation terminated.
> ```
> This header file isn't there in the include directory. Is netinet a
> dependency fo ptpd? If so, you'll have to find the package that
> provides netinet, and add that to rsb in a similar manner as in ptpd,
> then you'll have to add it in the ptpd.bset .
>

I have tried in this course. Have to still execute. Chris is telling there
is a problem with Canadian Cross
Compiling this. Is it allowed here to implement?

>
> > Attaching the log file as well.
> > - Mritunjay
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems/rsb]: Adding PTP support to RSB [GSoC 2020]

2020-05-20 Thread Mritunjay Sharma 
On Wed, May 20, 2020 at 5:42 AM Chris Johns  wrote:

> On 20/5/20 5:57 am, Mritunjay Sharma wrote:
> > On Wed, May 20, 2020 at 1:15 AM Vijay Kumar Banerjee  > > wrote:
> >
> > On Wed, May 20, 2020 at 12:52 AM Mritunjay Sharma
> > mailto:mritunjaysharma...@gmail.com>>
> > wrote:
> >  >
> >  >
> >  >
> >  > On Tue, May 19, 2020 at 10:09 PM Vijay Kumar Banerjee
> > mailto:vi...@rtems.org>> wrote:
> >  >>
> >  >> On Tue, May 19, 2020 at 7:42 PM Mritunjay Sharma
> >  >>  > > wrote:
> >  >> >
> >  >> > Hello everyone,
> >  >> >
> >  >> > Starting this thread to discuss and give a detail of my
> > progress in relation to
> >  >> > my GSoC 2020 project "BSP Buildset for EPICS".
> >  >> >
> >  >> > It is to tell that I have worked on adding ptp2 support as
> > suggested by mentors
> >  >> > The implementation that I found could work was ptp2 daemon and
> > so worked with
> >  >> > it.
> >  >> >
> >  >> > I added these files:
> >  >> > rsb/rtems/config/net/ptpd-2.3-1.cfg
> >  >> > rsb/rtems/config/net/ptpd.bset
> >  >> > rsb/source-builder/config/ptpd-2.1.cfg
> >  >> >
> >  >> > I am attaching the .diff file and the bug that I have
> > encountered in the
> >  >> > respective txt file and will like the help of mentors in
> > trying to help me
> >  >> > fix it.
>
> I am seeing in the RSB log this ...
>
> + pwd
> +
>
> build_top=/home/mritunjay/development/rtems/rsb/rtems/build/ptpd-2.3.1-sparc-rtems5-1
> + test x86_64-linux-gnu != sparc-rtems5
> + test -z  -o sparc-rtems5 ==
> /home/mritunjay/development/rtems/rsb/rtems/build/ptpd-2.3.1-sparc-rtems5-1/do-build:
>
> 102: test: sparc-rtems5: unexpected operator
>
> Is there a shell script error here?
>
> It is not clear to me why this error did not stop the build?
>
> Please add --trace to the RSB command line. It does create lots of
> output but it does help debug these things.
>

Have added and attached. Please have a look. Thanks
-Mritunjay


> >  >> >
> >  >> Hi Mritrynjay,
> >  >>
> >  >> The error your are facing is here:
> >  >> ```
> >  >> checking whether the C compiler works... no
> >  >> configure: error: in
> >  >>
> >
>  
> `/home/mritunjay/development/rtems/rsb/rtems/build/ptpd-2.3.1-sparc-rtems5-1/build-cxc':
> >  >> configure: error: C compiler cannot create executables
> >  >> ```
> >  >> Looks like it's not able to find the CC properly. If I remember
> >  >> correctly, you had a similar problem before. Do you remember how
> you
> >  >> fixed that or what was missing?
> >  >>
> >  > Thank you so much for the help, Vijay. However, the thing that
> > was working last time is not
> >  > helping me this time. I am attaching the config.log as well. Hope
> > it will help with debugging.
> >
> > Thanks for the log files. From a quick look, there is one obvious
> > error, the linker can't find libbsd most probably because it is not
> > there. So, you need to remove the -lbsd option from ptpd-2-1.cfg file
> > LIBS value. Another thing to be noted is that there are a few errors
> > due to failed version checking of the sparc-rtems5-gcc, this can
> > probably ignored for now if removing the -lbsd option fixes your
> > issue.
> >
> > Thank you so much! Removing the lbsd from cfg file resloved the earlier
> > compiler issue but now another error is coming up and it is somewhat
> > like this:
> >   "Makefile:502: recipe for target 'all-recursive' failed
> > make[1]: Leaving directory
> >
> '/home/mritunjay/development/rtems/rsb/rtems/build/ptpd-2.3.1-sparc-rtems5-1/build-cxc'
>
> This looks like a Canadian Cross compile and this does not seem right.
> It may be related to the shell script error above.
>
> Chris
>
RTEMS Tools Project - Source Builder Error Report
 Build: error: building ptpd-2.3.1-sparc-rtems5-1
 Command Line: ../source-builder/sb-set-builder --log=log_sis_net_snmp 
--prefix=/home/mritunjay/development/rtems/5 
--with-tools=/home/mritunjay/development/rtems/5 --host=sparc-rtems5 
--with-rtems-bsp=erc32 net/ptpd --trace
 Python: 2.7.17 (default, Apr 15 2020, 17:20:14) [GCC 7.5.0]
 
git://git.rtems.org/rtems-source-builder.git/origin/855818015a378a8333754625296f3b15ce52aadd-modified
 Linux mritunjay-XPS-15-9570 5.3.0-51-generic #44~18.04.2-Ubuntu SMP Thu Apr 23 
14:27:18 UTC 2020 x86_64
Tail of the build log:
drwxr-xr-x stigge/stigge  0 2015-06-29 20:41 ptpd-2.3.1/tools/ptplib/
drwxr-xr-x stigge/stigge  0 2015-06-29 20:41 ptpd-2.3.1/tools/ptplib/man/
-rw-r--r-- stigge/stigge   1638 2015-06-29 20:41 
ptpd-2.3.1/tools/ptplib/man/ptpLogRead.Rd
-rw-r--r-- stigge/stigge   2535 2015-06-29 20:41 
ptpd-2.3.1/tools/ptplib/man/ptpStats.Rd
-rw-r--r-- stigge/stigge   1289 2015-06-29 20:41 
ptpd-2.3.1/tools/ptplib/man/ptpQualityCompare.Rd
-rw-r--r--

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

2020-05-20 Thread Utkarsh Rai 
On Wed, May 20, 2020 at 7:40 AM Hesham Almatary 
wrote:

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

[PATCH 1/1] smpsignal01: Change state before sending the signal

2020-05-20 Thread Jan Sommer 
The signal handler of the consumer might start executing
before rtems_signal_send of the producer returns.
Therefore change the state to SIG_1_SENT before sending the signal.
---
 testsuites/smptests/smpsignal01/init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/testsuites/smptests/smpsignal01/init.c 
b/testsuites/smptests/smpsignal01/init.c
index 36a66bea9b..025e84c6a2 100644
--- a/testsuites/smptests/smpsignal01/init.c
+++ b/testsuites/smptests/smpsignal01/init.c
@@ -81,10 +81,10 @@ static void signal_send(test_context *ctx, test_state 
new_state)
 {
   rtems_status_code sc;
 
+  change_state(ctx, new_state);
   sc = rtems_signal_send(ctx->consumer, TEST_SIGNAL);
   rtems_test_assert(sc == RTEMS_SUCCESSFUL);
 
-  change_state(ctx, new_state);
 }
 
 static void check_consumer_processor(const test_context *ctx)
-- 
2.12.3

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

[PATCH 0/1] smpsignal01: Change state before sending signal

2020-05-20 Thread Jan Sommer 
I noticed during running the smpsignal test that it sometimes succeeds
and sometimes fails when running with qemu.
It looks like the signal handler sometimes starts execution faster than
the sender can update the state variable.

This patch updates the variable right before sending, so that the state
always has the correct value for the handler to process.

Best regards,

   Jan

Jan Sommer (1):
  smpsignal01: Change state before sending the signal

 testsuites/smptests/smpsignal01/init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.12.3

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