Spectre PoC compiled for MorphOS, courtesy of Chain-Q:

http://charlie.amigaspirit.hu/temp/private/spectre/

I can confirm that the PPC970 is vulnerable :-)

And people say MorphOS isn't a modern OS!

It's another proof that we have the best programmers, and with this killer-app we're a clear leader in the whole Amiga world. :LOL:

P.S. I can't wait to try this application on my MorphOS computer.

> Power9 platform

Current state of mitigations/fixes against the Meltdown and Spectre vulnerabilities in IBM POWER microprocessors:

http://wiki.raptorcs.com/wiki/Speculative_Execution_Vulnerabilities_of_2018

Addendum:

>> Will MorphOS also be Spectre and Meltdown compatible? ;-)

> It's already Spectre-compatible on PowerPC / Power Architecture ;-)

Regarding Meltdown:

When IBM revealed some weeks ago that POWER7(+), POWER8(+) and POWER9 (pre-current steppings) were vulnerable to Meltdown, they failed to give any information on pre-POWER7 processors. 3 days ago this follow-up was published:

"IBM will not be releasing patches for POWER4, POWER5, POWER6 systems and recommends migrating to a more current generation of POWER technology. [...] on February 6, we will introduce an offer for pre-POWER7 clients to upgrade their security profile and protect against Spectre and Meltdown through the purchase of POWER8 or POWER9 systems and available migration services, security support, and financing offers."
https://www.ibm.com/blogs/psirt/potential-impact-processors-power-family/

Does this mean POWER4 might be vulnerable to Meltdown? And if so, this would mean the POWER4-derived G5/PPC970 is most likely vulnerable as well, right?

As the Spectre fix also requires a CPU microcode update, then any board requires a BIOS update. A software fix on its own isn't enough.

Even if by some miracle you could get MC to release microcode updates for PPC, you can't deploy them. Is the MorphOS team in the habit of updating OF and UBoot firmwares?

> Even if by some miracle you could get MC to release microcode updates for PPC

Who is MC?

> Is the MorphOS team in the habit of updating OF and UBoot firmwares?

I don‘t think anybody believes it is.

Quote:

Motorola and/or IBM, depending on chip. I tend to just refer to MC, just saves too much pointless wordage.

>> Who is MC?

> Motorola and/or IBM, depending on chip.

Motorola won‘t provide any microcode updates for PPC, that‘s for sure ;-) I’ve never seen "MC" used with that meaning. Is this an actual abbreviation of something in this context, or just some random letters?

> I tend to just refer to MC, just saves too much pointless wordage.

Yes, obviously ;-)

Quote:

As far as I know it comes from the MC prefix of some of their earliest consumer chips, i.e. the MC6800 and MC68000. My use of it was by no means an industry standard, just something informal I thought was common in Amiga circles in decades past. I'm sorry to disappoint with a mundane explanation but it probably just stood for 'Motorola Chip'. I can't be bothered following the progress of any relationship between old Motorola and new, and their collaboration with IBM and so on or who would be responsible for what. Nobody's going to update the chips in any case.

...and so the wordage was not avoided

Edit: the term in use http://tinyurl.com/y79eh3jz

[ Edited by KennyR 05.02.2018 - 23:41 ]

>>>> Who is MC?

>>> Motorola and/or IBM

>> I’ve never seen "MC" used with that meaning.

> As far as I know it comes from the MC prefix of some of their earliest consumer chips [...],
> just something informal I thought was common in Amiga circles in decades past.

As said, I‘ve never seen it formally or informally used that way. What I’ve seen for Motorola (and probably used myself) is the short form "Moto". I‘m not aware of any formal or informal abbreviation describing "Motorola and/or IBM". There is "AIM", describing a 1990s alliance between Apple, IBM and Motorola.

> I can't be bothered following the progress of any relationship between old Motorola and new

The evolution of the chip company has been as follows (with announced/intended steps in brackets):
Motorola SPS -> Freescale -> NXP (-> Qualcomm -> Broadcom)

The remaining non-SPS Motorola split in 2011 into Motorola Mobility and Motorola Solutions, which exist to this date.

> the term in use http://tinyurl.com/y79eh3jz

I don‘t see where "MC" is used as short form for the company Motorola (let alone "Motorola and/or IBM"). The "MC" in those few hits is the part number prefix and is used to tell fully qualified chips (MC...) from less qualified chips (XC.../PC...).

Addendum:

> vulnerable CPUs are those that do speculative execution.

I‘m not sure what to make of these comments:

"Older PPCs see to be immune. Also the embedded cores on ACube/A-Eon hardware, actually."
https://twitter.com/chainq/status/968234699616325632

"the current AmigaOne lineup is not affected, AFAIK."
https://twitter.com/chainq/status/969652393892859910

The e5500 (and e500v2) not doing speculative execution?

Addendum:

> The e5500 (and e500v2) not doing speculative execution?

"The affected cores are e500, e500mc, e5500, e6500."
https://lists.ozlabs.org/pipermail/linuxppc-dev/2018-May/173807.html


Edit:
According to this official NXP document, e600 is affected as well (but not the older G4 core in MPC7400/MPC7410, see also link in comment #24).

[ Edited by Andreas_Wolf 06.03.2021 - 11:10 ]

Even if our hardware is vulnerable, who is going to target our small community?

> Even if our hardware is vulnerable, who is going to target our small community?

From a technical viewpoint, Spectre is irrelevant for MorphOS anyway (see comments #8, #9 and #10).

Quote:

And the last paragraph of comment #2...
Yes, I get your point.

I guess my next question would be will an X64 fork (with whatever changes that brings) present any issues?

> will an X64 fork (with whatever changes that brings) present any issues?

Depends on the changes, I'd say. For current MorphOS ported to x64 as is, there'd be no difference to current MorphOS on Power Architecture. A MorphOS/x64 with memory protection and SMP on the other hand would require mitigations against Spectre, Meltdown and Foreshadow to not be vulnerable to those exploits.

Quote:

Thanks, that is what I thought. Introduce memory protection, and then the exploits that defeat it become a problem.

Well, we can only hope that hardware/cpu vendors work on this while we are in transition.

Update:

> "The affected cores are e500, e500mc, e5500, e6500."
> https://lists.ozlabs.org/pipermail/linuxppc-dev/2018-May/173807.html

NXP PowerPC Processors Finally Being Mitigated Against Spectre V2 With Linux 4.21

Addendum:

>> Cell BE and Xenon/XCGPU may not be able to do speculative execution
>> in which case they wouldn't be vulnerable.

> https://randomascii.wordpress.com/2018/01/07/finding-a-cpu-design-bug-in-the-xbox-360
> hints at Xenon/XCGPU being able to do speculative execution.
> If so, this should also be true for the Cell BE PPE.

There's indeed a Power(PC) core without speculative execution:

"A2 [...] was [...] the only modern processor core that we have heard of that did not have speculative execution in its circuits. Speculative execution has hit all commercial processors with the Spectre and Meltdown security vulnerabilities that Google revealed in January 2018 in varying degrees, but this is not a concern with those using the [...] A2 core."
https://www.nextplatform.com/2020/06/30/big-blue-open-sources-the-core-inside-bluegene-q-supercomputers/

This core has recently been opened.