From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp105.iad3a.emailsrvr.com (smtp105.iad3a.emailsrvr.com [173.203.187.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E7E573B2A4 for ; Thu, 4 Jan 2018 15:28:54 -0500 (EST) Received: from smtp6.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp6.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 7918E55E4; Thu, 4 Jan 2018 15:28:54 -0500 (EST) X-SMTPDoctor-Processed: csmtpprox beta Received: from smtp6.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp6.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 739B55677; Thu, 4 Jan 2018 15:28:54 -0500 (EST) Received: from app8.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp6.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 5ABCF55E4; Thu, 4 Jan 2018 15:28:54 -0500 (EST) X-Sender-Id: dpreed@deepplum.com Received: from app8.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Thu, 04 Jan 2018 15:28:54 -0500 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app8.wa-webapps.iad3a (Postfix) with ESMTP id 4AC0160A8C; Thu, 4 Jan 2018 15:28:54 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Thu, 4 Jan 2018 15:28:54 -0500 (EST) X-Auth-ID: dpreed@deepplum.com From: "dpreed@deepplum.com" To: "Dave Taht" Cc: "Jonathan Morton" , cerowrt-devel@lists.bufferbloat.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20180104152854000000_52292" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: <2D7460E1-C724-4DAE-86CA-2D48AB2DAFE5@gmail.com> Message-ID: <1515097734.30384822@apps.rackspace.com> X-Mailer: webmail/12.9.10-RC X-Mailman-Approved-At: Mon, 30 Mar 2020 07:21:13 -0400 Subject: Re: [Cerowrt-devel] =?utf-8?q?KASLR=3A_Do_we_have_to_worry_about_othe?= =?utf-8?q?r_arches_than_x86=3F?= 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: , Date: Thu, 04 Jan 2018 20:28:55 -0000 X-Original-Date: Thu, 4 Jan 2018 15:28:54 -0500 (EST) X-List-Received-Date: Thu, 04 Jan 2018 20:28:55 -0000 ------=_20180104152854000000_52292 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AMeltdown is very easy to exploit, and doesn't need heavy CPU usage (well= , the obvious exploit is dumping all of kernel data space, which might be s= omewhat slower than a memcpy() of that data. :-)=0A =0AEssentially, you run= a loop that uses speculative memory tests to load a unique userspace cache= line for each bit of kernel memory, and after loading some cache lines, yo= u check to see if those userspace locations are in the cache. If you stick = lo L1 cache, you can do this concurrently on multiple cores. But you don't = need multiple cores, one will do.=0A =0AThat assumes that you are running a= program that wants to read your kernel data looking for passwords in the c= lear, etc.=0A =0ASceptre may require heavy CPU usage, but Meltdown doesn't.= =0A =0ADepending on how you set up your "home router", you might allow "inf= ected" or "trojan" programs to run in userspace there. I wouldn't do that, = because hardware is cheap. But some people like to throw all kinds of serve= r code into their router setups - even stuff like node.js servers.=0A =0ATh= e really core issue with Meltdown at the highest level is that the kernel i= s addressable from userspace, except for the "privilege level" in the page = table entries. That's a couple of bits between userspace and data that user= space isn't supposed to ever see. And those bits are ignored during specutl= ative execution's memory accesses.=0A =0A-----Original Message-----=0AFrom:= "Dave Taht" =0ASent: Thursday, January 4, 2018 9:53am= =0ATo: "Jonathan Morton" =0ACc: cerowrt-devel@lists.= bufferbloat.net=0ASubject: Re: [Cerowrt-devel] KASLR: Do we have to worry a= bout other arches than x86?=0A=0A=0A=0AOn Thu, Jan 4, 2018 at 6:49 AM, Jona= than Morton wrote:=0A>> On 4 Jan, 2018, at 3:59 pm,= Dave Taht wrote:=0A>>=0A>> Alan cox has been doing a= good job of finding the good stuff. Power=0A>> and the IBM z-series are al= so affected.=0A>=0A> Conversely, the ARM-1176, Cortex-A7 and Cortex-A53 cor= es used by various iterations of the Raspberry Pi are not affected. These a= re all in-order execution CPUs with short pipelines, and I think they're re= presentative of what you'd want in CPE.=0A=0AWell, I'd hope that this strin= g of bugs stalls deployment of more=0Aadvanced arches in this space until t= he speculative execution bugs are=0Afully resolved.=0A=0A(and I *vastly* pr= efer short pipelines)=0A=0A> - Jonathan Morton=0A>=0A=0A=0A=0A-- =0A=0ADave= T=C3=A4ht=0ACEO, TekLibre, LLC=0Ahttp://www.teklibre.com=0ATel: 1-669-226-= 2619=0A_______________________________________________=0ACerowrt-devel mail= ing list=0ACerowrt-devel@lists.bufferbloat.net=0Ahttps://lists.bufferbloat.= net/listinfo/cerowrt-devel ------=_20180104152854000000_52292 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Meltdown is very easy = to exploit, and doesn't need heavy CPU usage (well, the obvious exploit is = dumping all of kernel data space, which might be somewhat slower than a mem= cpy() of that data. :-)

=0A

 

=0A

Essentially, you run a loop that uses speculative memory tests to= load a unique userspace cache line for each bit of kernel memory, and afte= r loading some cache lines, you check to see if those userspace locations a= re in the cache. If you stick lo L1 cache, you can do this concurrently on = multiple cores. But you don't need multiple cores, one will do.

=0A

 

=0A

That assumes that you are= running a program that wants to read your kernel data looking for password= s in the clear, etc.

=0A

 

=0A

Sceptre may require heavy CPU usage, but Meltdown doesn't.

=0A

 

=0A

Depending on how you se= t up your "home router", you might allow "infected" or "trojan" programs to= run in userspace there. I wouldn't do that, because hardware is cheap. But= some people like to throw all kinds of server code into their router setup= s - even stuff like node.js servers.

=0A

 

= =0A

The really core issue with Meltdown at the highest = level is that the kernel is addressable from userspace, except for the "pri= vilege level" in the page table entries. That's a couple of bits between us= erspace and data that userspace isn't supposed to ever see. And those bits = are ignored during specutlative execution's memory accesses.

=0A

 

=0A

-----Original Message-----From: "Dave Taht" <dave.taht@gmail.com>
Sent: Thursday, Janu= ary 4, 2018 9:53am
To: "Jonathan Morton" <chromatix99@gmail.com>=
Cc: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-de= vel] KASLR: Do we have to worry about other arches than x86?

=0A

=0A

On Thu, Jan 4,= 2018 at 6:49 AM, Jonathan Morton <chromatix99@gmail.com> wrote:
>> On 4 Jan, 2018, at 3:59 pm, Dave Taht <dave.taht@gmail.com>= wrote:
>>
>> Alan cox has been doing a good job of f= inding the good stuff. Power
>> and the IBM z-series are also af= fected.
>
> Conversely, the ARM-1176, Cortex-A7 and Cortex-= A53 cores used by various iterations of the Raspberry Pi are not affected. = These are all in-order execution CPUs with short pipelines, and I think the= y're representative of what you'd want in CPE.

Well, I'd hope th= at this string of bugs stalls deployment of more
advanced arches in th= is space until the speculative execution bugs are
fully resolved.

(and I *vastly* prefer short pipelines)

> - Jonathan M= orton
>



--

Dave T=C3=A4ht
C= EO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
_______________________________________________
Cerowrt-devel mailin= g list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbl= oat.net/listinfo/cerowrt-devel

=0A
 ------=_20180104152854000000_52292--