Will MorphOS also be Spectre and Meltdown compatible?
Intel's PR team says "it's well-defined behaviour",
acknowledged by Trump: "greatest processor ever".

BTW here are the bugs for ARM.

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

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

http://tenfourfox.blogspot.com/2018/01/is-powerpc-susceptible-to-spectre-yep.html
http://tenfourfox.blogspot.com/2018/01/more-about-spectre-and-powerpc-or-why.html

In short, any OS on any CPU that does speculative execution is Spectre-vulnerable unless appropriate software measures are taken in the OS. And also with PowerPC the general rule applies that the older the CPU the more resilient it is against the vulnerability (except for future CPUs that will have counter-measures implemented).

However, I suspect that MorphOS can't be patched against Spectre because of its singular address space nature. A comment by a MorphOS team member on this would be appreciated.

Thanks Andreas!
Maybe we should have support for Clamshell iBooks for best security

Which means we need to go back to in-order PPC processors guys!
Hey, IBM had some cool cpus built for the PS3 and the Xbox360 that were in-order.
And a neat successor for the former, until they dropped development.

SO...Andreas, what ARE the current in-order cpu options?

> Which means we need to go back to in-order PPC processors

In-order execution doesn't preclude speculative execution (branch prediction etc.).

http://morph.zone/modules/newbb_plus/viewtopic.php?forum=3&topic_id=7183&start=272

> IBM had some cool cpus built for the PS3 and the Xbox360 that were in-order.

...and the POWER6 as well (which can do speculative execution, though, so is vulnerable). But yes, Cell BE and Xenon/XCGPU may not be able to do speculative execution in which case they wouldn't be vulnerable.


Edit: added link regarding POWER6

[ Edited by Andreas_Wolf 29.01.2018 - 13:32 ]

Hmm, you already addressed that, huh?

OK, what DOESN'T have branch prediction?

> you already addressed that, huh?

It was minator who did back then :-)

> what DOESN'T have branch prediction?

Confusingly, Spectre seems to be more complicated than that as I just read. For instance, both Cortex-A8 and Cortex-A53 are in-order and do branch prediction, but Cortex-A53 is not vulnerable according to Arm Holdings (as linked by polluks) whereas Cortex-A8 is. So it seems to depend on how the branch predictor works specifically.

There's a recent discussion: https://forum.level1techs.com/t/list-of-cpus-most-likely-immune-to-spectre/123128

And this:

"POWER9 is being patched and will not be vulnerable at ship, and there will be no performance loss versus current #POWER9 samples. Patches coming soon."
https://twitter.com/RaptorCompSys/status/949368929507520517
https://social.raptorengineering.io/notice/883

"only the DD2.2 silicon changes were needed. DD2.2 silicon is able to close off these security holes, with the exception of the Spectre same-process read vulnerability that affects the entire CPU industry, with only changes to firmware and a small kernel change."
https://social.raptorengineering.io/notice/887


Edit: As Eben Upton explains, there can be branch prediction without speculative execution. This is where I was confused, thinking the former would require the latter. It's the other way round: speculative execution can only happen after branch prediction has taken place. So as I wrote in my initial comment, vulnerable CPUs are those that do speculative execution. Branch prediction alone doesn't suffice.

[ Edited by Andreas_Wolf 21.03.2018 - 22:16 ]

"Will MorphOS also be Spectre and Meltdown compatible?"

The flaws in these CPUs allowed any running process to peer into the memory space of any other.

MorphOS and AmigaOS already have that flaw by design, they don't need the CPU to allow it.

Quote:

Good point. And as a 'flaw' its something that I never addressed while use 68K processors (the lack of memory protection).
But then, I was using an OS that only allowed for position independent code, hard coding specific memory writes was frowned on...so, the primary problems in that type of environment are bad coding techniques and errors in the the OS, or memory mapping that would allow one application to overwrite the memory allocated to another.

> Good point.

Yes, see last paragraph in comment #2 :-)

Quote:

You know, now that I think about it, I am curious about one thing.
Wouldn't removing hard coded address writes (forcing everything through a memory allocation manager in the kernel) provide a similar level of intervention as the 68K environments I previously mentioned.

> Wouldn't removing hard coded address writes (forcing everything through
> a memory allocation manager in the kernel) provide a similar level of
> intervention as the 68K environments I previously mentioned.

You mean changing AmigaOS/MorphOS to something different, inherently incompatible? Then see thread title.

Quote:

I'm guessing it would have to support privilege levels (or rings). If a legitimate process could use a kernel memory map benignly, then malware could use it just as easily.

I personally wouldn't even begin to know how this could be slotted into MorphOS or even just quark and remain compatible.

Quote:

Well, we are already discussing dropping some compatibility in order to support SMP and a larger address range.

Yes, this would tweak compatibility quite a bit, but I don't think it would be that easy malware to circumvent.
The nice thing about micro kernel structure is that its better protected than monolithic kernels.
And the processes would not actually access the memory mapper, they would just trigger requests for services that would for the most part be transparent.
Basically its a little like have an MMU in software.

AND, the approach REALLY reduced system lockups when implemented in 68K based systems.

>I'm guessing it would have to support privilege levels (or rings).

If I'm not mistaken this is usually how a micro kernel is implemented, with the most vital components being located at the core, and successive layers/rings like an onion wrapped around that core.

BTW - That document Andreas mentioned does seem to offer some hope for AMD's Zen architecture.

[ Edited by Jim 05.01.2018 - 20:42 ]

Quote:

“Some?” Either you follow the Amiga specification (compatible) or you don’t (incompatible). For example, Amiga has a unified memory architecture. Protected memory (as in Micro Kernels) is incompatible.

MorphOS x64 will be incompatible. It won’t even be source-code compatible.

Quote:

Yes, 32 or 64 bit memory maps and SMP, that's not compatible with the Amiga 'specification'.

As to how micro-kernel OS' protect memory, have you ever used one that offered that function?
Its worth the sacrifice as it improves stability.

SO, since we're already contemplating a move that will render MorphOS incompatible, why NOT consider some form of memory protection?

We certainly have a kernel that should be easy to adapt to it.

> The nice thing about micro kernel structure is that its better protecte
> than monolithic kernels.

Yes, but in terms of MorphOS, what we really have from Quark viewpoint is one single task (ABox) running on it. Almost everything that we consider "MorphOS" is happening within this task and its address space where everything can read from and write to everywhere. So as long as MorphOS/PPC is supposed to stay compatible with the past, the advantages of a microkernel won't help. That's reserved for future, incompatible MorphOS versions (on another ISA, see thread title).

> As to how micro-kernel OS' protect memory [...] Its worth the sacrifice as it improves stability.

That's the sacrifice that's supposed to be made for the future, incompatible version of MorphOS (on another ISA, see thread title).

> since we're already contemplating a move that will render MorphOS incompatible,
> why NOT consider some form of memory protection?

Future MorphOS on another ISA is planned to have memory protection. A backport of that version to 64-bit PPC would include all features, including the incompatibility with current MorphOS.

Quote:

i also expect a future MorphOS NG to have memory protection, but I remember an old moobunny thread where IIIRC were key MorphOS developer(s) (IIRC Laire) were talking about pros and cons of MP and and that MP is not a definitive given for future developments. But I think from today's view MP is rather a must for security reasons. Back then it the main view perspective was rather system stability/integrity.

> But I think from today's view MP is rather a must for security reasons. Back then it the main view perspective was rather system stability/integrity.

Yes, from my point of view, stability is still the main advantage.
Then again, MorphOS has already proven itself (to me anyway) to be a remarkably stable platform (I get more crashes in Windows).

And yes Andreas, I understand this would likely only be adopted in MorphOS NG.

Although, personally, I'd take an incompatible MorphOS PPC that supported MP, SMP, and a larger address space (Amiga compatibility was never that big an issue with me, we could always use UAE, and some of the existing MorphOS software should be modifiable to handle these changes).

After all, if we'd decided to stay with PPCs (say shifting to a Power9 platform), I'd be advocating these changes as necessary to fully utilize the hardware anyway (which we are NOT doing now).

> I remember an old moobunny thread where IIIRC were key MorphOS developer(s) (IIRC
> Laire) were talking about [...] that MP is not a definitive given for future developments.

That must have been before 2011, when first real plans to go x64 or ARM with all bells and whistles were announced at Alchimie 111111. And MorphOS team member geit has never grown tired during the last years of explaining how MorphOS/x64 is supposed to get memory protection.

> some of the existing MorphOS software should be modifiable to handle these changes

All software could be adapted, as long as it's still being developed or open source.

Quote:

Then you see my point.
These features need to be implemented to fully utilize our hardware.
Since there is a plan to move to X64 and adopt these changes, I'm finally looking forward to X64 (as we have something worthwhile to anticipate).

But our multi-core PPCs could also benefit from these changes.
And the T2080 laptop I've been advocating simply would be wasted as a MorphOS platform without it.

So, once the ISA change has been adopted, I'm still in favor of back-porting some of MorphOS NG to MorphOS PPC.

Update:

> http://tenfourfox.blogspot.com/2018/01/is-powerpc-susceptible-to-spectre-yep.html
> http://tenfourfox.blogspot.com/2018/01/more-about-spectre-and-powerpc-or-why.html

Actual tests:

http://tenfourfox.blogspot.com/2018/01/actual-field-testing-of-spectre-on.html

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.