From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 15F293B2A4 for ; Thu, 4 Jan 2018 08:38:29 -0500 (EST) Received: by mail-qk0-x235.google.com with SMTP id o126so1905426qke.12 for ; Thu, 04 Jan 2018 05:38:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=LuS5mZquyN/n020skMlgyhaFk6kP6W+PymKOqtdxOGI=; b=sPkHj2BNXWoWtDXHc1c1S+PLlZT4bY9nreaiqrLzlxduaHzKB+cfLxhd95cf8txAv9 tmxTB2K9x7JlMYMnJJv0Sm8QCNIGnHAaHqcPXEqaFLK+SpRVIh7kYvQl2xYlnhXpivfO IC50/tgva9azp+GeijW15ronyMIQYBQZhJpOeHilXOb3wNb4lYM7rCZos7isSFVMeF9e E/AdLFwcYwtaIdkdKip7kjLVEJfY7nCQShU772/UPlAe1kMx6SJz4oBvAZBRtNnenWwx LxvAOA39VjndKDLoUDKiJfmpPxWKDd5Trq2lwVklDvYZaEJFretGcxXIE3do/bq64wIu 5UHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=LuS5mZquyN/n020skMlgyhaFk6kP6W+PymKOqtdxOGI=; b=ktu7jgXjtKaSOF2Lmri2jZo897jeoaCp1wIABq6odbyT7ncDRUORIeh17/4HESOuR1 Yuurv1Gk1yDxPbS6S+uIE1vjOqHAxpFv/v3pVCeL/KZw59OtVJ7jVQtVdVRVj8edufBF WvzSthqMFDLng2xU/2JkWtHKs0vxIWVIUY0s/6gHUSd8YUiDtOsLcCzUjSVb8/oyLdoH Ejb4MBRQD0YhXfKTgKmis753gmV9AbwBspk+Gxrm7s3nIirlicqhQP7X5SVKo42qXL/0 kCDUbt0pHgz0glt0NQrlv4lfhv6KbKmYddX6lUrtp8B2F2Czea6/xT43mT3YTKhOOPs7 yivQ== X-Gm-Message-State: AKGB3mJzDSx2kZTkpPQAFnYP0XbbtadMDZqlByyIa2zXvSSmr8R+mqzz OBYqnmFd8sPNy2jI/sGUV/7ZYy+Dn/bvY0zONkk= X-Google-Smtp-Source: ACJfBoskUf9bITx3WYdKOtfXFxoY/QjA3iPyLrHOP+w4VTNtbicewYpQPudaujEBK6j0szzRF5oBghs3gr2yHrCqPkw= X-Received: by 10.55.73.143 with SMTP id w137mr5866114qka.17.1515073108530; Thu, 04 Jan 2018 05:38:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.193.93 with HTTP; Thu, 4 Jan 2018 05:38:27 -0800 (PST) In-Reply-To: References: From: Dave Taht Date: Thu, 4 Jan 2018 05:38:27 -0800 Message-ID: To: Jonathan Morton Cc: cerowrt-devel@lists.bufferbloat.net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86? X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 13:38:29 -0000 On Thu, Jan 4, 2018 at 4:09 AM, Jonathan Morton wro= te: > Okay, it's a little bit more nuanced than I thought. In fact there are *= three* different CPU hardware vulnerabilities just disclosed. I've summari= sed the impact in this Reddit post: > > https://www.reddit.com/r/Amd/comments/7o2i91/technical_analysis_of_spectr= e_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 =3D 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 rela= tively low impact. It could potentially be exploited using JIT compilation= of untrusted eBPF or Javascript, but can only exfiltrate data from the loc= al process. > > - Spectre v2 affects most recent Intel CPUs and some recent, high-perform= ance ARM CPU cores, but not AMD to any significant degree. On vulnerable C= PUs, 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 the= ir unusually aggressive speculative behaviour regarding L1 cache hits. On = vulnerable CPUs, it allows a local attacker to exfiltrate data from privile= ged address space. > > I don't think we need to worry about it too much in a router context. Vi= rtual server folks, OTOH... > > - Jonathan Morton > --=20 Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619