Has RTEMS ever had a CVE?

[Schweikhardt, Jens (TSPCE6-TL5)]

Hello,

I wonder if RTEMS ever had a vulnerability for which a CVE was created
(only the RTEMS OS proper, not libbsd or newlib or other components).
Search engine results don’t turn up much, if anything, so I’m inclined to think 
the answer is “no”.
I found Gedare’s PDF about security hardening for EPICS/RTEMS talking a bit 
about
vulnerabilities, but that does not mention any true CVEs against RTEMS.
Can anyone say with certainty there are no CVEs against RTEMS?

Jens





Tesat-Spacecom GmbH & Co. KG
Sitz: Backnang; Registergericht: Amtsgericht Stuttgart HRA 270977
Persoenlich haftender Gesellschafter: Tesat-Spacecom Geschaeftsfuehrungs GmbH;
Sitz: Backnang; Registergericht: Amtsgericht Stuttgart HRB 271658;
Geschaeftsfuehrung: Thomas Reinartz, Kerstin Basche, Ralph Schmid

[banner]
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

AW: Running two RTEMS instances on two RISC-V harts

[Schweikhardt, Jens (TSPCE6-TL5)]

Hi Jan,

well, in the beginning there was a system with just one telescope. Now a second 
shall be added.
Easy as 1-2-3: duplicate the software and run it on two cores. No SW changes 
needed.
Developers like me are expensive J That’s how corporate thinks.

Driving a telescope involves not just a single driver, it’s a symphony of 10 
tasks
juggling tele-commands and telemetry data. Turning a singleton application into 
a
multi-telescope app would probably require extensive changes. There is a lot of 
data
that needs to be part of that context struct you suggest. Running two 
“unmodified”
RTEMS instances would make that easy: the context structs are the data segments.
(Which is why running two RTEMS instances from the /same/ address does NOT work:
they overwrite their data segment objects and trash each others stacks, etc. Can
this be avoided with linker script magic?).

About the disclaimer, I think I can get rid of the first one, the second is due 
to
corporate lawyers fearing getting their pants sued off and auto-appended by the 
mailhost. GRRR.

Thanks for taking the time to help me find a way how to proceed.

Jens


Von: jan.som...@dlr.de 
Gesendet: Montag, 24. Oktober 2022 14:13
An: Schweikhardt, Jens (TSPCE6-TL5) ; 
users@rtems.org
Betreff: RE: Running two RTEMS instances on two RISC-V harts


Externe E-Mail: Bitte Absender und Inhalt der Mail prüfen, bevor Dateianhänge 
oder Links geöffnet werden!
Hi Jens,

Is there a real need to have the telescope driver twice in memory?
Would it be enough to implement the driver as “object oriented” in C?
Then you would just need to create a context struct during initialization based 
on the hartid with the correct interrupt assignment and base address of the 
memory mapped registers.

At least that is a common pattern in the driver implementations of RTEMS.

Best regards,

Jan

PS: It is probably a good idea to remove the disclaimer in your email footer 
before posting to a public mailinglist.

From: users mailto:users-boun...@rtems.org>> On Behalf 
Of Schweikhardt, Jens (TSPCE6-TL5)
Sent: Montag, 24. Oktober 2022 13:53
To: 'users@rtems.org' mailto:users@rtems.org>>
Subject: Running two RTEMS instances on two RISC-V harts

hello, world\n

we’re currently in the design phase for a rocketchip RISC-V project with two 
harts.
Think a common HW platform where each hart drives a separate telescope unit.
The C code for each telescope is basically identical with the exception of 
memory mapped registers and interrupts.
Our idea is to compile the C code twice and link with different linkerscripts, 
separating the images in RAM
via different MEMORY { RAM: ORIGIN = 0x } declarations. A bootloader 
loads the images
to different addresses and branches depending on mhartid, starting two separate 
RTEMS applications, each
of which runs 10 tasks. There’s no communication between the RTEMS instances.

Are we attempting something crazy (too complex) and we should instead look into 
?

If not, is there a simple way to compile an app twice for different RAM: ORIGIN 
values?
I tried using a Linkerscript with -Wl,-T,Linkerscript with a different MEMORY 
but this draws a warning such as
warning: redeclaration of memory region `RAM'
and uses the value in the BSPs  linkcmds file. It looks like the last 
declaration wins and the linkcmds is
always read after linker scripts specified by my -Wl command line option.



Tesat-Spacecom GmbH & Co. KG
Sitz: Backnang; Registergericht: Amtsgericht Stuttgart HRA 270977
Persoenlich haftender Gesellschafter: Tesat-Spacecom Geschaeftsfuehrungs GmbH;
Sitz: Backnang; Registergericht: Amtsgericht Stuttgart HRB 271658;
Geschaeftsfuehrung: Thomas Reinartz, Kerstin Basche, Ralph Schmid

[banner]
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Running two RTEMS instances on two RISC-V harts

[Schweikhardt, Jens (TSPCE6-TL5)]

hello, world\n

we’re currently in the design phase for a rocketchip RISC-V project with two 
harts.
Think a common HW platform where each hart drives a separate telescope unit.
The C code for each telescope is basically identical with the exception of 
memory mapped registers and interrupts.
Our idea is to compile the C code twice and link with different linkerscripts, 
separating the images in RAM
via different MEMORY { RAM: ORIGIN = 0x } declarations. A bootloader 
loads the images
to different addresses and branches depending on mhartid, starting two separate 
RTEMS applications, each
of which runs 10 tasks. There’s no communication between the RTEMS instances.

Are we attempting something crazy (too complex) and we should instead look into 
?

If not, is there a simple way to compile an app twice for different RAM: ORIGIN 
values?
I tried using a Linkerscript with -Wl,-T,Linkerscript with a different MEMORY 
but this draws a warning such as
warning: redeclaration of memory region `RAM'
and uses the value in the BSPs  linkcmds file. It looks like the last 
declaration wins and the linkcmds is
always read after linker scripts specified by my -Wl command line option.

Jens Schweikhardt

TL4 LCT Software Development

Phone:

Mail:

+49 7191 930-2849

jens.schweikha...@tesat.de

[logo]



Tesat-Spacecom GmbH & Co. KG
Gerberstraße 49
71522 Backnang

[fb][li][tw]


This electronic message may contain highly confidential or privileged 
information from Tesat-Spacecom GmbH & Co. KG. Any of the information is only 
intended for the recipient and the use by any other party is not authorized. If 
you are not the intended recipient, be aware, that any disclosure, copying, 
distribution or use of the contents of this message is prohibited. If you have 
received this message by error please notify us immediately by telephone (+49 
7191 930-2849) or by e-mail (jens.schweikha...@tesat.de). Thank you.






Tesat-Spacecom GmbH & Co. KG
Sitz: Backnang; Registergericht: Amtsgericht Stuttgart HRA 270977
Persoenlich haftender Gesellschafter: Tesat-Spacecom Geschaeftsfuehrungs GmbH;
Sitz: Backnang; Registergericht: Amtsgericht Stuttgart HRB 271658;
Geschaeftsfuehrung: Thomas Reinartz, Kerstin Basche, Ralph Schmid

[banner]
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

AW: Problems with docs on docs.rtems.org

[Schweikhardt, Jens (TSPCE6-TL5)]

I opened ticket #4861
Jens



Tesat-Spacecom GmbH & Co. KG
Sitz: Backnang; Registergericht: Amtsgericht Stuttgart HRA 270977
Persoenlich haftender Gesellschafter: Tesat-Spacecom Geschaeftsfuehrungs GmbH;
Sitz: Backnang; Registergericht: Amtsgericht Stuttgart HRB 271658;
Geschaeftsfuehrung: Thomas Reinartz, Kerstin Basche, Ralph Schmid

[banner]
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Problems with docs on docs.rtems.org

[Schweikhardt, Jens (TSPCE6-TL5)]

Hello *,

It seems there is a problem with the docs on docs.rtems.org.
All the orange icon “HTML” links in the “Single HTML” column lead to an empty 
page.
Can anyone confirm this?

The pdf links look ok.

Jens




Tesat-Spacecom GmbH & Co. KG
Sitz: Backnang; Registergericht: Amtsgericht Stuttgart HRA 270977
Persoenlich haftender Gesellschafter: Tesat-Spacecom Geschaeftsfuehrungs GmbH;
Sitz: Backnang; Registergericht: Amtsgericht Stuttgart HRB 271658;
Geschaeftsfuehrung: Thomas Reinartz, Kerstin Basche, Ralph Schmid

[banner]
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Anyone using Xiphos Q8 (Zynq UltraScale+ MPSoc)?

[Schweikhardt, Jens (TSPCE6-TL5)]

Hello, world

Is anyone using Xiphos’s Q8 boards? It features a Zynq UltraScale+ MPSoC and
out of the box comes with an SDK for Yocto Linux 2.5 (sumo).
I realize RTEMS has some support for a BSP using the Zynq UltraScale+.
I wonder what the challenges would be using RTEMS instead of Linux.
Is it more than replacing a Linux rootfs image with an RTEMS application image,
providing a device tree and booting via Xilinx’s uboot?

Regards,
Jens




Tesat-Spacecom GmbH & Co. KG
Sitz: Backnang; Registergericht: Amtsgericht Stuttgart HRA 270977
Persoenlich haftender Gesellschafter: Tesat-Spacecom Geschaeftsfuehrungs GmbH;
Sitz: Backnang; Registergericht: Amtsgericht Stuttgart HRB 271658;
Geschaeftsfuehrung: Thomas Reinartz, Kerstin Basche, Ralph Schmid

[banner]
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users