Broken link in RSB documentation

[Mohammed Saeed Khoory]

Hi,

I found a broken link in the source builder documentation:

https://docs.rtems.org/rsb/#_windows

The ready to go windows tools link doesn't work.

Hope this helps,
Mohammed Khoory
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

SOCIS 2015 Evaluation of Fault Tolerance Project

[Saeed Ehteshamifar]

Hi

I am sending this email because Joel told us, participants of ESA SOCIS
2015, to submit our work to devel@RTEMS for evaluation.

In this summer of code I was supposed to add a fault injection tool work
with RTEMS. I've selected two tools for this purpose:

   - GRINDER : A free open-source
   tool for test case execution and for storing test results on database.
   - Slingshot : A free open-source
   tool to generate test campaigns for data-type based faults.

The links above refer to the original version of these tools, which are
designed for Linux and working on it. Here is what I've done:

   - GRINDER-RTEMS : Extending
   GRINDER to a new target, that is RTEMS on QEMU. Basically GRINDER supports
   no target but it is a base platform to add support for other targets.
   GRINDER-RTEMS has added this support by implementation of an interface
   (CUEAbstraction) which invokes the target (in this case QEMU), get back
   target output (in this case via console output), and store it on database.
   - Slingshot-RTEMS :
   Adaption of Slingshot to RTEMS. Originally Slingshot generates test
   campaigns to test implementation of POSIX API on Linux Standard Base.
   Slingshot-RTEMS runs on Linux, but generates code to test RTEMS
   implementation of a subset of POSIX API. A subset, because due to different
   process model, it is no possible to implement functions such as fork or
   exec* on RTEMS.
   - Documentation of the project can be found under:
   http://rtems-fi.blogspot.com/

Looking forward to hearing your feedbacks. Thanks!


Kind Regards,

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

Re: PATCH] untar: do not exit with error when created directory already exists (fixes #2413).

[Gedare Bloom]

Do we still have two versions of the untar code?

This looks good to commit.

On Mon, Sep 7, 2015 at 5:23 AM, Pavel Pisa  wrote:
> ---
>  cpukit/libmisc/untar/untar.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/cpukit/libmisc/untar/untar.c b/cpukit/libmisc/untar/untar.c
> index aed8fed..4591a8b 100644
> --- a/cpukit/libmisc/untar/untar.c
> +++ b/cpukit/libmisc/untar/untar.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -203,6 +204,13 @@ Untar_FromMemory(
>}
>  } else if (linkflag == DIRTYPE) {
>if ( mkdir(fname, S_IRWXU | S_IRWXG | S_IRWXO) != 0 ) {
> +if (errno == EEXIST) {
> +  struct stat stat_buf;
> +  if ( stat(fname, _buf) == 0 ) {
> +if (  S_ISDIR(stat_buf.st_mode) )
> +  continue;
> +  }
> +}
>  printk("Untar: failed to create directory %s\n", fname);
>  retval = UNTAR_FAIL;
>  break;
> --
> 1.9.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

[PATCH v2] untar: do not exit with error when created directory already exists (fixes #2413).

[Pavel Pisa]

The problem exists for both RTEMS untar implementations and their
variants: Untar_FromMemory(), Untar_FromFile() and rtems_tarfs_load().
---
 cpukit/libfs/src/imfs/imfs_load_tar.c | 12 +++-
 cpukit/libmisc/untar/untar.c  | 18 +-
 2 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/cpukit/libfs/src/imfs/imfs_load_tar.c 
b/cpukit/libfs/src/imfs/imfs_load_tar.c
index 7228978..2d4ca6b 100644
--- a/cpukit/libfs/src/imfs/imfs_load_tar.c
+++ b/cpukit/libfs/src/imfs/imfs_load_tar.c
@@ -103,8 +103,18 @@ int rtems_tarfs_load(
 strcat(full_filename, "/");
   ++len;
   strncat(full_filename, filename, 256-len-1);
-  rv = mkdir(full_filename, S_IRWXU | S_IRWXG | S_IRWXO);
+  if ( mkdir(full_filename, S_IRWXU | S_IRWXG | S_IRWXO) != 0 ) {
+if (errno == EEXIST) {
+  struct stat stat_buf;
+  if ( stat(full_filename, _buf) == 0 ) {
+if (  S_ISDIR(stat_buf.st_mode) )
+  continue;
+  }
+}
+rv = -1;
+  }
 }
+
 /*
  * Create a LINEAR_FILE node
  */
diff --git a/cpukit/libmisc/untar/untar.c b/cpukit/libmisc/untar/untar.c
index aed8fed..2c1e304 100644
--- a/cpukit/libmisc/untar/untar.c
+++ b/cpukit/libmisc/untar/untar.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -203,6 +204,13 @@ Untar_FromMemory(
   }
 } else if (linkflag == DIRTYPE) {
   if ( mkdir(fname, S_IRWXU | S_IRWXG | S_IRWXO) != 0 ) {
+if (errno == EEXIST) {
+  struct stat stat_buf;
+  if ( stat(fname, _buf) == 0 ) {
+if (  S_ISDIR(stat_buf.st_mode) )
+  continue;
+  }
+}
 printk("Untar: failed to create directory %s\n", fname);
 retval = UNTAR_FAIL;
 break;
@@ -319,7 +327,15 @@ Untar_FromFile(
 close(out_fd);
   }
 } else if (linkflag == DIRTYPE) {
-  (void) mkdir(fname, S_IRWXU | S_IRWXG | S_IRWXO);
+  if ( mkdir(fname, S_IRWXU | S_IRWXG | S_IRWXO) != 0 ) {
+if (errno == EEXIST) {
+  struct stat stat_buf;
+  if ( stat(fname, _buf) == 0 ) {
+if (  S_ISDIR(stat_buf.st_mode) )
+  continue;
+  }
+}
+  }
 }
   }
   free(bufr);
-- 
1.9.1

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

Re: Memory protection on RTEMS?

[Daniel Gutson]

El 9/9/2015 16:14, "Gedare Bloom"  escribió:
>
> On Wed, Sep 9, 2015 at 2:54 PM, Sebastian Huber
>  wrote:
> > Hello Martin,
> >
> > - Martin Galvan  schrieb:
> >> Hi there! We were looking at the RTEMS SMP support, and wondered what
> >> would it take for the system to support some form of memory protection
> >> (say, an MPU). Is it possible, and if so, how hard would it be?
> >
> > the question is, what is "some form of memory protection" for you?
> >
> +1. Requirements differ in this space. Note that we do not intend to
> have supervisor-privilege, so memory protection may be more applicable
> for safety features or debugging, rather than security. Security is
> guaranteed only if you can ensure no code injection and you have a
> trusted code base.
>
> > A process model for RTEMS makes no sense. For this you better use a
micro kernel or Linux.

We want to protect a real time task's memory from being written or
generally accessed from another task. That smells like processes, but the
truth is we just need memory iisolation/protection meaning that a task
trying to access something marked as owned by another task is because there
is a bug and an action shall be taken (e.g. restart the offending task). Is
there already any kind of hardware support for this?

Thanks,

  Daniel.

> >
> > The ARMv7-A and some PowerPC BSPs have write protection for code and
read-only data. On some BSPs, read/write to the NULL pointer leads to an
exception.  This is quite handy during development, but offers no real
benefit for a production system.
> >
> > For one customer we implemented a stack protection, a thread can only
access its own stack, but this is quite non-standard.
> >
> >>
> >> We also saw this:
> >>
> >> https://devel.rtems.org/wiki/Projects/MMU_Support
> >>
> >> What's the status of this project?
> >
> > I don't know. MMU support tends to be highly architecture specific, so
the development of a general purpose API is quite difficult.
> >
> I am (as we speak) working on a proposal to look in this direction.
> I'm happy to talk more or to consider how to align our efforts.
>
> >>
> >> On the other hand, we noticed that LEON3 IP Cores usually implement an
> >> MMU instead of just an MPU. Would it be feasible to support that?
> >
> > The GR740 has an IOMMU (chapter 17).
> >
> > http://microelectronics.esa.int/ngmp/GR740-UM-DS-v1.pdf
> >
> > --
> > 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.huber at 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: Memory protection on RTEMS?

[Joel Sherrill]

On 9/9/2015 5:27 PM, Daniel Gutson wrote:


El 9/9/2015 16:14, "Gedare Bloom" > 
escribió:
 >
 > On Wed, Sep 9, 2015 at 2:54 PM, Sebastian Huber
 > > wrote:
 > > Hello Martin,
 > >
 > > - Martin Galvan > schrieb:
 > >> Hi there! We were looking at the RTEMS SMP support, and wondered what
 > >> would it take for the system to support some form of memory protection
 > >> (say, an MPU). Is it possible, and if so, how hard would it be?
 > >
 > > the question is, what is "some form of memory protection" for you?
 > >
 > +1. Requirements differ in this space. Note that we do not intend to
 > have supervisor-privilege, so memory protection may be more applicable
 > for safety features or debugging, rather than security. Security is
 > guaranteed only if you can ensure no code injection and you have a
 > trusted code base.
 >
 > > A process model for RTEMS makes no sense. For this you better use a micro 
kernel or Linux.

We want to protect a real time task's memory from being written or generally 
accessed from another task. That smells like processes, but the truth is we 
just need memory iisolation/protection meaning that a task trying to access 
something marked as owned by another task is because there is a bug and an 
action shall be taken (e.g. restart the offending task). Is there already any 
kind of hardware support for this?


Saying "task's memory" needs to be more specific. There are a fair
number of different types of data including code, global data and BSS,
stack, per thread data, etc.

I assume the project Sebastian mentioned ended up with similar issues
for the one we implemented MMU-based stack protection for. Once you
define the "per task memory object" you want to protect, you have to
allocate it on the correct alignment boundary to use the MMU. On that
project, all task stacks were a fixed multiple of the page size and
the mapped address space protected that.

Beyond the alignment issues, somehow you have to manage the sets of
MMU data structures. Are there enough for the number of tasks and
objects. But this is implementation.

From a requirements view, let's drill down on what types of memory
objects there are and what makes sense.

+ code
+ data/bss
+ read only data
+ per thread data
+ stacks
+ C program heap
+ RTEMS Workspace
+ ?

As Sebastian mentioned if you make the task stack accessible by only
a single stack, you have to be careful not to pass pointers to objects
on the stack into paths where they will be used by another task.

But in general terms, once we look at the various types of logical
memory objects, we can decide what protection makes sense, alignment
impacts, page table limitations, etc.

--joel


Thanks,

   Daniel.

 > >
 > > The ARMv7-A and some PowerPC BSPs have write protection for code and 
read-only data. On some BSPs, read/write to the NULL pointer leads to an exception.  
This is quite handy during development, but offers no real benefit for a production 
system.
 > >
 > > For one customer we implemented a stack protection, a thread can only 
access its own stack, but this is quite non-standard.
 > >
 > >>
 > >> We also saw this:
 > >>
 > >> https://devel.rtems.org/wiki/Projects/MMU_Support
 > >>
 > >> What's the status of this project?
 > >
 > > I don't know. MMU support tends to be highly architecture specific, so the 
development of a general purpose API is quite difficult.
 > >
 > I am (as we speak) working on a proposal to look in this direction.
 > I'm happy to talk more or to consider how to align our efforts.
 >
 > >>
 > >> On the other hand, we noticed that LEON3 IP Cores usually implement an
 > >> MMU instead of just an MPU. Would it be feasible to support that?
 > >
 > > The GR740 has an IOMMU (chapter 17).
 > >
 > > http://microelectronics.esa.int/ngmp/GR740-UM-DS-v1.pdf
 > >
 > > --
 > > 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.huber at embedded-brains.de 
 > > PGP : Public key available on request.
 > >
 > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.



--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] untar: do not exit with error when created directory already exists (fixes #2413).

[Gedare Bloom]

Looks good. This should go on 4.11 and master? Someone can commit.

On Wed, Sep 9, 2015 at 6:09 PM, Pavel Pisa  wrote:
> The problem exists for both RTEMS untar implementations and their
> variants: Untar_FromMemory(), Untar_FromFile() and rtems_tarfs_load().
> ---
>  cpukit/libfs/src/imfs/imfs_load_tar.c | 12 +++-
>  cpukit/libmisc/untar/untar.c  | 18 +-
>  2 files changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/cpukit/libfs/src/imfs/imfs_load_tar.c 
> b/cpukit/libfs/src/imfs/imfs_load_tar.c
> index 7228978..2d4ca6b 100644
> --- a/cpukit/libfs/src/imfs/imfs_load_tar.c
> +++ b/cpukit/libfs/src/imfs/imfs_load_tar.c
> @@ -103,8 +103,18 @@ int rtems_tarfs_load(
>  strcat(full_filename, "/");
>++len;
>strncat(full_filename, filename, 256-len-1);
> -  rv = mkdir(full_filename, S_IRWXU | S_IRWXG | S_IRWXO);
> +  if ( mkdir(full_filename, S_IRWXU | S_IRWXG | S_IRWXO) != 0 ) {
> +if (errno == EEXIST) {
> +  struct stat stat_buf;
> +  if ( stat(full_filename, _buf) == 0 ) {
> +if (  S_ISDIR(stat_buf.st_mode) )
> +  continue;
> +  }
> +}
> +rv = -1;
> +  }
>  }
> +
>  /*
>   * Create a LINEAR_FILE node
>   */
> diff --git a/cpukit/libmisc/untar/untar.c b/cpukit/libmisc/untar/untar.c
> index aed8fed..2c1e304 100644
> --- a/cpukit/libmisc/untar/untar.c
> +++ b/cpukit/libmisc/untar/untar.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -203,6 +204,13 @@ Untar_FromMemory(
>}
>  } else if (linkflag == DIRTYPE) {
>if ( mkdir(fname, S_IRWXU | S_IRWXG | S_IRWXO) != 0 ) {
> +if (errno == EEXIST) {
> +  struct stat stat_buf;
> +  if ( stat(fname, _buf) == 0 ) {
> +if (  S_ISDIR(stat_buf.st_mode) )
> +  continue;
> +  }
> +}
>  printk("Untar: failed to create directory %s\n", fname);
>  retval = UNTAR_FAIL;
>  break;
> @@ -319,7 +327,15 @@ Untar_FromFile(
>  close(out_fd);
>}
>  } else if (linkflag == DIRTYPE) {
> -  (void) mkdir(fname, S_IRWXU | S_IRWXG | S_IRWXO);
> +  if ( mkdir(fname, S_IRWXU | S_IRWXG | S_IRWXO) != 0 ) {
> +if (errno == EEXIST) {
> +  struct stat stat_buf;
> +  if ( stat(fname, _buf) == 0 ) {
> +if (  S_ISDIR(stat_buf.st_mode) )
> +  continue;
> +  }
> +}
> +  }
>  }
>}
>free(bufr);
> --
> 1.9.1
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Memory protection on RTEMS?

[Sebastian Huber]

Hello Martin,

- Martin Galvan  schrieb:
> Hi there! We were looking at the RTEMS SMP support, and wondered what
> would it take for the system to support some form of memory protection
> (say, an MPU). Is it possible, and if so, how hard would it be?

the question is, what is "some form of memory protection" for you?

A process model for RTEMS makes no sense. For this you better use a micro 
kernel or Linux.

The ARMv7-A and some PowerPC BSPs have write protection for code and read-only 
data. On some BSPs, read/write to the NULL pointer leads to an exception.  This 
is quite handy during development, but offers no real benefit for a production 
system.

For one customer we implemented a stack protection, a thread can only access 
its own stack, but this is quite non-standard.

> 
> We also saw this:
> 
> https://devel.rtems.org/wiki/Projects/MMU_Support
> 
> What's the status of this project?

I don't know. MMU support tends to be highly architecture specific, so the 
development of a general purpose API is quite difficult.

> 
> On the other hand, we noticed that LEON3 IP Cores usually implement an
> MMU instead of just an MPU. Would it be feasible to support that?

The GR740 has an IOMMU (chapter 17).

http://microelectronics.esa.int/ngmp/GR740-UM-DS-v1.pdf

-- 
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.huber at 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: Memory protection on RTEMS?

[Gedare Bloom]

On Wed, Sep 9, 2015 at 2:54 PM, Sebastian Huber
 wrote:
> Hello Martin,
>
> - Martin Galvan  schrieb:
>> Hi there! We were looking at the RTEMS SMP support, and wondered what
>> would it take for the system to support some form of memory protection
>> (say, an MPU). Is it possible, and if so, how hard would it be?
>
> the question is, what is "some form of memory protection" for you?
>
+1. Requirements differ in this space. Note that we do not intend to
have supervisor-privilege, so memory protection may be more applicable
for safety features or debugging, rather than security. Security is
guaranteed only if you can ensure no code injection and you have a
trusted code base.

> A process model for RTEMS makes no sense. For this you better use a micro 
> kernel or Linux.
>
> The ARMv7-A and some PowerPC BSPs have write protection for code and 
> read-only data. On some BSPs, read/write to the NULL pointer leads to an 
> exception.  This is quite handy during development, but offers no real 
> benefit for a production system.
>
> For one customer we implemented a stack protection, a thread can only access 
> its own stack, but this is quite non-standard.
>
>>
>> We also saw this:
>>
>> https://devel.rtems.org/wiki/Projects/MMU_Support
>>
>> What's the status of this project?
>
> I don't know. MMU support tends to be highly architecture specific, so the 
> development of a general purpose API is quite difficult.
>
I am (as we speak) working on a proposal to look in this direction.
I'm happy to talk more or to consider how to align our efforts.

>>
>> On the other hand, we noticed that LEON3 IP Cores usually implement an
>> MMU instead of just an MPU. Would it be feasible to support that?
>
> The GR740 has an IOMMU (chapter 17).
>
> http://microelectronics.esa.int/ngmp/GR740-UM-DS-v1.pdf
>
> --
> 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.huber at 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

Memory protection on RTEMS?

[Martin Galvan]

Hi there! We were looking at the RTEMS SMP support, and wondered what
would it take for the system to support some form of memory protection
(say, an MPU). Is it possible, and if so, how hard would it be?

We also saw this:

https://devel.rtems.org/wiki/Projects/MMU_Support

What's the status of this project?

On the other hand, we noticed that LEON3 IP Cores usually implement an
MMU instead of just an MPU. Would it be feasible to support that?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: PATCH] untar: do not exit with error when created directory already exists (fixes #2413).

[Pavel Pisa]

Hello Gedare,

On Wednesday 09 of September 2015 17:05:43 Gedare Bloom wrote:
> Do we still have two versions of the untar code?

There is another implementation which is IMFS specific.
It is invoked by function rtems_tarfs_load() located in

  rtems/cpukit/libfs/src/imfs/imfs_load_tar.c

It is better optimized that it does not copy data from image
to RAM. But on the other hand is specific for IMFS only.

The corrected implementation

  rtems/cpukit/libmisc/untar/untar.c

is generic untar code which is independent on filesystem.
So it can be used (in theory) to untar file to FAT or other
filesystems  and supports untar from memory Untar_FromMemory()
and Untar_FromFile(). It has disadvantage that does not easily
support to specify location where to untar when compared
with rtems_tarfs_load().

So both implementations are not 1:1 feature equivalent.
The rtems_tarfs_load() has been introduced in 2000 year.

We use Untar_FromMemory() in our application but it may
be more for historical reasons than that use of rtems_tarfs_load()
would not provide same function and rtems_tarfs_load() is much
less memory hungry than Untar_FromMemory().

But I think that it would worth to fix untar.c when it is present.
It correctly worked in previous releases and (as I have located now)
has been broken at commit e075b388728408e8745408c8dbdbe9635ccea399
  untar: check return value from mkdir
by Gedare Bloom :-)

Best wishes,

 Pavel

> This looks good to commit.
>
> On Mon, Sep 7, 2015 at 5:23 AM, Pavel Pisa  wrote:
> > ---
> >  cpukit/libmisc/untar/untar.c | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/cpukit/libmisc/untar/untar.c b/cpukit/libmisc/untar/untar.c
> > index aed8fed..4591a8b 100644
> > --- a/cpukit/libmisc/untar/untar.c
> > +++ b/cpukit/libmisc/untar/untar.c
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel