MorphOS x64
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    polluks
    Posts: 778 from 2007/10/23
    From: Gelsenkirchen,...
    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.
    Pegasos II G4: MorphOS 3.9, Zalman M220W · iMac G5 12,1 17", MorphOS 3.18
    Power Mac G3: OSX 10.3 · PowerBook 5,8: OSX 10.5, MorphOS 3.18
  • »05.01.18 - 15:41
    Profile
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    polluks
    Posts: 778 from 2007/10/23
    From: Gelsenkirchen,...
    Thanks Andreas!
    Maybe we should have support for Clamshell iBooks for best security :-)
    Pegasos II G4: MorphOS 3.9, Zalman M220W · iMac G5 12,1 17", MorphOS 3.18
    Power Mac G3: OSX 10.3 · PowerBook 5,8: OSX 10.5, MorphOS 3.18
  • »05.01.18 - 16:04
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4977 from 2009/1/28
    From: Delaware, USA
    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?
    "Never attribute to malice what can more readily explained by incompetence"
  • »05.01.18 - 18:56
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 12058 from 2003/5/22
    From: Germany
    > 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 ]
  • »05.01.18 - 21:15
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4977 from 2009/1/28
    From: Delaware, USA
    Hmm, you already addressed that, huh?

    OK, what DOESN'T have branch prediction?
    "Never attribute to malice what can more readily explained by incompetence"
  • »05.01.18 - 21:22
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 12058 from 2003/5/22
    From: Germany
    > 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 ]
  • »05.01.18 - 22:11
    Profile
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    KennyR
    Posts: 868 from 2003/3/4
    From: #AmigaZeux, Gu...
    "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.
  • »05.01.18 - 22:14
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4977 from 2009/1/28
    From: Delaware, USA
    Quote:

    KennyR wrote:
    "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.


    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.
    "Never attribute to malice what can more readily explained by incompetence"
  • »05.01.18 - 22:30
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 12058 from 2003/5/22
    From: Germany
    > Good point.

    Yes, see last paragraph in comment #2 :-)
  • »05.01.18 - 22:36
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4977 from 2009/1/28
    From: Delaware, USA
    Quote:

    Andreas_Wolf wrote:
    > Good point.

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


    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.
    "Never attribute to malice what can more readily explained by incompetence"
  • »05.01.18 - 23:00
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 12058 from 2003/5/22
    From: Germany
    > 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.
  • »06.01.18 - 00:11
    Profile
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    KennyR
    Posts: 868 from 2003/3/4
    From: #AmigaZeux, Gu...
    Quote:

    Andreas_Wolf wrote:
    > 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.


    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.
  • »06.01.18 - 00:33
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4977 from 2009/1/28
    From: Delaware, USA
    Quote:

    KennyR wrote:
    Quote:

    Andreas_Wolf wrote:
    > 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.


    . 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.


    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 ]
    "Never attribute to malice what can more readily explained by incompetence"
  • »06.01.18 - 01:35
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    takemehomegrandma
    Posts: 2720 from 2003/2/24
    Quote:

    we are already discussing dropping some compatibility


    “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.
    MorphOS is Amiga done right! :-)
    MorphOS NG will be AROS done right! :-)
  • »06.01.18 - 02:46
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4977 from 2009/1/28
    From: Delaware, USA
    Quote:

    takemehomegrandma wrote:
    Quote:

    we are already discussing dropping some compatibility


    “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.


    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.
    "Never attribute to malice what can more readily explained by incompetence"
  • »06.01.18 - 03:12
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 12058 from 2003/5/22
    From: Germany
    > 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).
  • »06.01.18 - 12:35
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 12058 from 2003/5/22
    From: Germany
    > 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.
  • »06.01.18 - 12:59
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Zylesea
    Posts: 2053 from 2003/6/4
    Quote:

    Andreas_Wolf schrieb:


    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.


    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.
    --
    http://via.bckrs.de

    Whenever you're sad just remember the world is 4.543 billion years old and you somehow managed to exist at the same time as David Bowie.
    ...and Matthias , my friend - RIP
  • »06.01.18 - 15:03
    Profile Visit Website
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4977 from 2009/1/28
    From: Delaware, USA
    > 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).
    "Never attribute to malice what can more readily explained by incompetence"
  • »06.01.18 - 16:20
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 12058 from 2003/5/22
    From: Germany
    > 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.
  • »06.01.18 - 16:28
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 12058 from 2003/5/22
    From: Germany
    > 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.
  • »06.01.18 - 16:39
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4977 from 2009/1/28
    From: Delaware, USA
    Quote:

    Andreas_Wolf wrote:
    > 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.


    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.
    "Never attribute to malice what can more readily explained by incompetence"
  • »06.01.18 - 17:30
    Profile