From gedare at rtems.org  Tue Oct  8 21:42:56 2024
From: gedare at rtems.org (Gedare Bloom)
Date: Tue, 8 Oct 2024 15:42:56 -0600
Subject: Deprecating Architectures and BSPs after 6 Branches
In-Reply-To: <CAF9ehCWcVRe-HvTkqtXNW_=b_GM4j3sFCw4+3fsevo=ief1DOw@mail.gmail.com>
References: <CAF9ehCWcVRe-HvTkqtXNW_=b_GM4j3sFCw4+3fsevo=ief1DOw@mail.gmail.com>
Message-ID: <CAC82fA2PC5xpGGz38CZ3tK839rTyD4d5D_mkbmbXxYLjk6jppQ@mail.gmail.com>

A minor update, we have added several more m68k boards to the mrm332
board for deprecation in 6 and removal in 7:
m68k/csb360
m68k/gen68340
m68k/gen68360
m68k/gen68360_040
m68k/pgh360
m68k/mcf5206elite
m68k/mcf52235
m68k/mcf5225x
m68k/mrm332
m68k/mvme147
m68k/mvme147s
m68k/mvme162
m68k/mvme162lx
m68k/mvme167

On Fri, May 31, 2024 at 2:32?PM Joel Sherrill <joel at rtems.org> wrote:
>
> Hi
>
> As the branching of 6 approaches, there have been discussions of deprecating some architectures entirely and some specific BSPs. This means they would be present in the 6.x series but not present in the 7.x series.
>
> Various factors play into the decision but include loss of compiler support and aging out of the hardware platform. Being old isn't enough -- we want to have confidence that no one is using RTEMS on that platform. For example, we have been told that m68040 MVME boards are still around in some labs. We will keep them. But the mrm332 board within the same m68k family is on the deprecation list after contacting the hardware vendor.
>
> A recent factor is lack of a maintainer to the point of not being able to get permission to relicense. We have a few architectures that do not appear to be in active use and the port authors have not responded to relicense requests.
>
> Architectures on the deprecation list are:
>
> + bfin, lm32, mips, sh, sparc64, and v850
>
> The BSP list isn't settled yet but looks likely to include old ARM boards like the gumstix and the original BeagleBoard. We think the m68k and powerpc families likely have BSPs which are no longer in use.
>
> As we continue the transition to GitLab, we want to leverage CI as much as practical. Reducing architectures and BSPs significantly impacts turn around time. I
>
> If you know of architectures or BSPs that you have stopped using or think have aged out, please let us know.  We really need user input.
>
> Conversely, if you are silently using something, let us know. It will keep it off the deprecation list for at least one more round. :)
>
> Thanks.
>
> --joel
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users

From gedare at rtems.org  Wed Oct 16 18:25:24 2024
From: gedare at rtems.org (Gedare Bloom)
Date: Wed, 16 Oct 2024 12:25:24 -0600
Subject: Security Concerns for RTEMS?
Message-ID: <CAC82fA0dHHsYCs2EU_XbBg+Zbu63c4LmYxkipc4aZoU6Rx2cvw@mail.gmail.com>

Hello RTEMS Users!

I'm looking for insight into whether any RTEMS users have concerns
that their organization may be impacted by potential vulnerabilities
in RTEMS or its continuous development, integration and deployment
infrastructure.

If you might, I'd be keen to speak with you about it!
Gedare

From lichx2 at sugon.com  Mon Oct 28 03:08:45 2024
From: lichx2 at sugon.com (lichx2 at sugon.com)
Date: Mon, 28 Oct 2024 11:08:45 +0800
Subject: aarch64 curr_el_sp0_irq/_AArch64_Exception_interrupt_nest use
 Incorrect sp
Message-ID: <OFBBA257EB.D8D764FC-ON48258BC4.0011482A-48258BC4.0011482D@sugon.com>

An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20241028/f8c3d94d/attachment.htm>

From kinsey.moore at oarcorp.com  Mon Oct 28 18:20:51 2024
From: kinsey.moore at oarcorp.com (Kinsey Moore)
Date: Mon, 28 Oct 2024 18:20:51 +0000
Subject: aarch64 curr_el_sp0_irq/_AArch64_Exception_interrupt_nest use
 Incorrect sp
In-Reply-To: <OFBBA257EB.D8D764FC-ON48258BC4.0011482A-48258BC4.0011482D@sugon.com>
References: <OFBBA257EB.D8D764FC-ON48258BC4.0011482A-48258BC4.0011482D@sugon.com>
Message-ID: <LV3PR19MB82784E5208B5B4B9D952239D904A2@LV3PR19MB8278.namprd19.prod.outlook.com>

Thanks for bringing this up. I couldn?t find the exact wording you mentioned, but I think this is what you?re referring to in the current (K.a) revision of the ARM Architecture reference manual for ARMv8:

D1.3.2 Exception entry
When an exception is taken to an Exception level, ELx, that is using AArch64 state, all the following occur:
* The contents of PSTATE immediately before the exception was taken is written to SPSR_ELx.
* The preferred exception return address is written to ELR_ELx.
* The contents of PSTATE immediately after the exception is taken is as described in rule RWTXBY.
* For synchronous exceptions and SError interrupts, exception syndrome information is written to ESR_ELx.
* Execution starts from the exception vector at the target Exception level.
When an exception is taken to an Exception level, ELx, that is using AArch64 state, after recording the previous
values in SPSR_ELx, the following PSTATE bits are set:
* PSTATE.EL is set to the target Exception level.
* All of PSTATE.{D, A, I, F, SP, TCO, PM} are set to 1.
?

It?s likely that this is transparently working by accident since nested interrupts occur and any stack usage is unrolled/undone before any dispatching can occur. The one place where this might actually show up as an issue is when the thread stack pointer is corrupted/misaligned, but that would trigger a non-irq exception which follows a different code path and likely does not allow for nested interrupts. This has been written up as an issue on the RTEMS GitLab instance: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5140

Thanks,
Kinsey

From: users <users-bounces at rtems.org> On Behalf Of lichx2 at sugon.com
Sent: Sunday, October 27, 2024 22:09
To: rtems-users at rtems.org
Subject: aarch64 curr_el_sp0_irq/_AArch64_Exception_interrupt_nest use Incorrect sp

Hi?
    curr_el_sp0_irq/_AArch64_Exception_interrupt_nest may use Incorrect sp.  ARM-ARM described "on exception entry to Elx, SP_ELx is automatically selected. so when curr_el_sp0_irq/_AArch64_Exception_interrupt_nest will use sp_el1(this is task sp not interrupt sp) . Use gdb to  verify curr_el_sp0_irq/_AArch64_Exception_interrupt_nest really use Incorrect sp.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20241028/ac849496/attachment.htm>