[Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

[Dave Taht]

On Thu, Jan 4, 2018 at 4:09 AM, Jonathan Morton <chromatix99 at gmail.com> wrote:
> Okay, it's a little bit more nuanced than I thought.  In fact there are *three* different CPU hardware vulnerabilities just disclosed.  I've summarised the impact in this Reddit post:
>
> https://www.reddit.com/r/Amd/comments/7o2i91/technical_analysis_of_spectre_meltdown/

On top of that, potential attacks are cpu-intensive as hell, at least
in their early stages.

I can't help but reflect on my favorite (sadly, still slidewire)
alternate cpu's characteristics, the mill.

It's a single address space in the first place, protection of memory
is to the byte, not the page (and done in a separate unit than the
TLB).
There are no syscalls, per se', instead an explicit capability gaining
(or dropping) portal call almost exactly like a subroutine.
the stack is protected from ROP. Stack and Registers have no rubble
(there are no registers, as we know them, either) that can be peered
at on call or return. Speculative execution is an intrinsic, well
documented part of the exposed processor pipeline: an explicit value
(NAR = not a result) is dropped anywhere there is the equivalent of
speculative execution. There isn't a conventional BTB, either (branch
exits are predicted via an undefined mechanism). In short, I think the
mill, as the closest thing to a pure capabilities arch that exists
today, would have (at least on paper) been invulnerable to this string
of attacks.

But the only way we'll ever find out is to build it. I keep calling
for more open processor designs (the risc-v is gaining some traction).
We really need more diversity in the infrastructure. I started
reminiscing fondly of the days when I used to use an old DEC alpha as
a firewall merely because I had more confidence it would be hard to
exploit than anything else.

I lay awake last night trying to figure out what the impact of these
bugs would be on the market. What I think will happen is everybody's
stock is going to go up as there is a mad rush to replace now 10-30%
slower hardware just to meet existing loads. Maybe power8 will regain
some traction. Cloud costs will jump, also, to compensate. (and it's
not just the cloud, anybody using a JIT on a desktop looks to be in
trouble - that includes java). And then, of course, would be a flood
of exploits over the next several years, attacking everything that
hasn't been patched.

And I'm hating the benchmarks thus far like that, because, latencies
are going to jump once again on servicing interrupts, and
that breaks a lot of assumptions in (for example) the virtualized
networking space, and context switches were already orders of
magnitude too slow for my taste and favorite applications (like
ardour.org).

> The TL;DR version is:
>
> - Spectre v1 affects pretty much any modern out-of-order CPU, but is relatively low impact.  It could potentially be exploited using JIT compilation of untrusted eBPF or Javascript, but can only exfiltrate data from the local process.
>
> - Spectre v2 affects most recent Intel CPUs and some recent, high-performance ARM CPU cores, but not AMD to any significant degree.  On vulnerable CPUs, it allows a local attacker to exfiltrate data from privileged address space.
>
> - Meltdown is the nasty one which Linux kernel devs have been scrambling to mitigate.  So far, it is known to affect only Intel x86 CPUs, due to their unusually aggressive speculative behaviour regarding L1 cache hits.  On vulnerable CPUs, it allows a local attacker to exfiltrate data from privileged address space.
>
> I don't think we need to worry about it too much in a router context.  Virtual server folks, OTOH...
>
>  - Jonathan Morton
>



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619