Spectre

[Silent-Hunter]

What, if anything, should the Pyra software devs do about this? Will the Pyra be vulnerable to these issues or is it something we shouldn't really worry about?

https://developer.arm.com/support/security-update

 

[levi]

Most of the information on these boards about this is captured here already: https://pyra-handheld.com/boards/threads/intelpocalypse.82304/

But it's perhaps worth having a thread for ARM spectre. Unfortunately thus far I've not been able to compile the exploits on my Pandora due to them including some x86 constants at the very least.

 

[Letalis Sonus]

Unfortunately thus far I've not been able to compile the exploits on my Pandora due to them including some x86 constants at the very least.

Don't worry about the Pandora, it is absolutely immune to those vulnerabilities. The Cortex-A8 has an in-order architecture, it does not use any kind of speculative execution. This kind of prediction mechanism only makes sense on an out-of-order architecture - which is why the early Intel Atoms are not affected as well.

 

[levi]

That's not what ARM says at the link above. However, I've looked up the second variant of attack that's identified as CVE2018-5715 and desribed by ARM as 'branch target injection'. However, I've looked it up on NIST and there it says it's 'Systems with microprocessors utilizing speculative execution and indirect branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis.'

If, as you say the A8 is an in-order processor (I was unable to verify this or disprove it when I last checked) then I don't see how ARM reckons it can affect that processor, but there you go.

 

[Letalis Sonus]

If, as you say the A8 is an in-order processor (I was unable to verify this or disprove it when I last checked)

Check this Cortex-A comparison on Wikipedia, the Cortex-A9 was the first one to introduce an out-of-order architecture. You can check this on ARM's own product page of the A8 as well. It is the only in-order CPU in that list, maybe they just mixed things up, the Cortex-A8 and its direct offsprings are the only Cortex-A class CPUs with an in-order architecture.

There's a lot of confusion going on around the whole issue, including Intel doing some serious PR bullshit trying to reduce the impact on their reputation. If you've got an idea about what all of this is about, take a look at their FAQ page about the issue - it cringes the hell out of me. And that one was even created *after* Torvalds ranted about Intel's PR bullshit due to them trying to enable the Meltdown workaround for all x86 CPUs.

 

[Silent-Hunter]

I'm just wondering what will need to be done to mitigate this on the Pyra. The link mentions some compiler changes, and recompiling code with those.

 

[sebt3]

From us ? Probably just make sure we're using the right configurations options for the kernel.
Debian have already updated its toolchains even the cross-compiling ones. I havent updated my pyra yet, but i'm pretty sure what need to be recompiled already have been updated by the debian security team

 

[Letalis Sonus]

Apparently there are some corner cases where the Meldown/Spectre issue (or at least something along the same line) may affect in-order architectures as well. The IBM Xenon CPU of the Xbox 360 has a custom prefetch instruction to bypass the L2 cache by making the L1 caches incoherent on purpose in order to save some of the limited L2 space for hardcore game optimizations - this instruction is already very dangerous to use in itself, but they screwed up wiring it up with the branch prediction as well: https://randomascii.wordpress.com/2018/01/07/finding-a-cpu-design-bug-in-the-xbox-360/

 

[hns]

There is an official document by ARM which says everything we can do: https://developer.arm.com/support/security-update
It seems as if Cortex A15 is affected but we can't change transistors
So we can only wait until the Linux kernel is hardened.

 

[levi]

From us ? Probably just make sure we're using the right configurations options for the kernel.
Debian have already updated its toolchains even the cross-compiling ones. I havent updated my pyra yet, but i'm pretty sure what need to be recompiled already have been updated by the debian security team

From what little I've picked up thus far, the kernel patches are mainly targetting meltdown flaws, in that they protect the kernel from being read by nasty user processes. There's also spectre flaws that let you e.g. read all RAM including other userspaces, and that ARM advisory seems focussed on those flaws to me.

But really the news thus far seems mostly designed to confuse anyone trying to work out which of their hardware is flawed and how exactly. I'm hoping the trend will be towards more concrete advice as the weeks go on.

 

[lukey]

http://kroah.com/log/blog/2018/01/06/meltdown-status/

 

[___]

in related news: a German journalist had apparently not quite understood the magnitude of the issue or what chip design actually means, because why bother to inform yourself before you blabber absurd shit. so she stated her opinion that "the look of the chips apparently is more important than security".
https://www.watson.ch/amp/!345905102 (article is in German)
hilarious

 

[oskda]

Pandora, with Cortex-A8, is inmune as this processor doesn't have especulative execution.

PYRA, with Cortex-A15, have the fault as this processor have especulative execution.

It is interesting to know that in 64 bits, low cores, like Cortex-A53 doesn't have the fault (no especulative execution), while higher cores, like Cortex-A57 and higher, have the fault (they have especulative execution).

Sometimes less is more.

 

[levi]

FWIW, the arm notification of these issues (which conflate spectre and meltdown to some degree I think). But it still reckons the A8 is potentially affected by CVE-2017-5753 and definitely affected by CVE-2017-5717 (but not CVE-2017-5754 or it's variant thus fair unpublished by ARM). Unfortunately NIST seems to be down for me at the moment, so I can't check the canonical definition of these exploits, but according to ARM (and MS who use the same classifications) 5737 is a bounds check bypass and 5717 is a branch target injection (which may be the same or similar to return-oriented coding, I'm not quite sure still).

The explots for spectre I've investigated thus far (which all seem to be minor tweaks of the same codebase), seem to be targetting CVE-2017-5717 which ARM classifies as a rogue data cache load. Neither the A8 or A15 are susceptible to that type of attack according to ARMs advisory.

ARMs advisors declare the A8 to have a very similar attack surface to the A15, so I would hesitate to declare a distance until I understand more about the specific holes as identified by NIST.

Edit: I wonder if NIST being down is related to the US government shutdown, rather than a DoS for a change. Different type of DoS I guess.

Edit: NIST is back now. Guess it's not due to the government shutdown then.

 

[Letalis Sonus]

Pandora, with Cortex-A8, is inmune as this processor doesn't have especulative execution.

It's not that it doesn't do speculative execution, the point is that if you are not going to reorder instructions for better performance you're simply doing a lot less speculation. See the link about the Xenon CPU I already posted, it's an in-order CPU like the A8 and the old Atoms that are said to not be vulnerable, but it still suffers from an essential design flaw related to speculative execution.

 

[levi]

If I understand it more precisely properly, I think that speculative execution is a pretty obvious minor improvement on out-of-order execution. Once you start shifting things around to use the processor more efficiently, you soon see stuff you could do ahead of time that might happen after an operation that might just fail in a specific situation that you can't assess ahead of time. The benefit of Out of Order execution is greatly limited if you decide not to implement speculative execution. And regarding spectre's rogue data cache load hole specifically, that's dependent on speculative execution as far as I understand how the code works.

 

[Klumpen]

https://www.zdnet.com/article/researchers-discover-splitspectre-a-new-spectre-like-cpu-attack/

Three academics from Northeastern University and three researchers from IBM Research have discovered a new variation of the Spectre CPU vulnerability that can be exploited via browser-based code.

 

[klapse]

It is really only the gimped webmonkey-designed websites that require more cpu than Pi3 A53.

 

[levi]

On an unrelated note, it disappoints me that apparently the latest ARM layouts released still don't contain the spectre fixes were were promised at the start of the year. According to the press release made then, it's part of the v8.5 updates, but the chips announced the other day (such as the A65ae announced earlier this week) only listed v8.1, v8.2 and partial v8.3 instructions in their feature lists. Hopefully, it's just a hole in the announcement and they are starting to bake mitigations into their silicon, but that it's not listed suggesting customers just don't care is a disappointment to me.

 

[Klumpen]

All Intel chips open to new Spoiler non-Spectre attack: Don't expect a quick fix
https://www.zdnet.com/article/all-i...r-non-spectre-attack-dont-expect-a-quick-fix/