From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp81.iad3a.emailsrvr.com (smtp81.iad3a.emailsrvr.com [173.203.187.81]) (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 E062B3B2A4 for ; Thu, 4 Jan 2018 17:09:19 -0500 (EST) Received: from smtp27.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp27.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 82C7A24B4F; Thu, 4 Jan 2018 17:09:19 -0500 (EST) X-SMTPDoctor-Processed: csmtpprox beta Received: from smtp27.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp27.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 7E20224CF2; Thu, 4 Jan 2018 17:09:19 -0500 (EST) Received: from app54.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp27.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 6206A24CAE; Thu, 4 Jan 2018 17:09:19 -0500 (EST) X-Sender-Id: dpreed@deepplum.com Received: from app54.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 17:09:19 -0500 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app54.wa-webapps.iad3a (Postfix) with ESMTP id 53AA2A0045; Thu, 4 Jan 2018 17:09:19 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Thu, 4 Jan 2018 17:09:19 -0500 (EST) X-Auth-ID: dpreed@deepplum.com Date: Thu, 4 Jan 2018 17:09:19 -0500 (EST) From: "dpreed@deepplum.com" To: "=?utf-8?Q?Joel_Wir=C4=81mu_Pauling?=" Cc: "Jonathan Morton" , cerowrt-devel@lists.bufferbloat.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20180104170919000000_74965" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: <1515103048.715224709@apps.rackspace.com> Message-ID: <1515103759.340132151@apps.rackspace.com> X-Mailer: webmail/12.9.10-RC 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: , X-List-Received-Date: Thu, 04 Jan 2018 22:09:20 -0000 ------=_20180104170919000000_74965 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AI don't disagree that anyone who can run code in the hypervisor itself c= an attack the guest instances.=0A =0ABut that has nothing to do with KALSR = or Meltdown or Sceptre. That's just bad security design - the rule is "the = principle of least privilege", which comes from the 1970's work on secure o= perating systems.=0A =0AI should point out here that I was one of the resea= rchers that helped develop the original multi-level security systems then. = Those "colored books" come from us.=0A =0A-----Original Message-----=0AFrom= : "Joel Wir=C4=81mu Pauling" =0ASent: Thursday, January = 4, 2018 5:00pm=0ATo: "dpreed@deepplum.com" =0ACc: "Jon= athan Morton" , cerowrt-devel@lists.bufferbloat.net= =0ASubject: Re: [Cerowrt-devel] KASLR: Do we have to worry about other arch= es than x86?=0A=0A=0A=0A=0ASRIOV ports and Vendor NIC optimizations wrt Lat= encies.=0A=0A=0AWhilst these heavy hitting NVF appliances tend to be large = and span multiple compute hosts (and therefore are the only tenannts on tho= se computes) - this isn't always the case. =0A=0A=0AIt's a problem in that = if you can get onto the hypervisor even as an unprivileged user you can rea= d out guest stores. .... Big Problem. =0A=0A=0AOn 5 January 2018 at 10:57, = [ dpreed@deepplum.com ]( mailto:dpreed@deepplum.com ) <[ dpreed@deepplum.co= m ]( mailto:dpreed@deepplum.com )> wrote:=0A=0AHmm... protection datacentre= s tend to require lower latencies than can be achieved running on hyperviso= rs.=0A =0AWhich doesn't mean that some datacenters don't do that.=0A =0AAs = far as NFV is concerned, Meltdown only breaks security if a userspace appli= cation is running on a machine where another user has data running through = kernel address space. NFV environments don't tend to run NFV in userspace u= nder an OS that has kernel data in the page tables that are reachable from = CR3.=0A =0AThe key issue in Meltdown is that CR3 is not changed between use= rspace and kernelspace. Which means that the memory access pipeline in user= space can use a kernelspace address (what Intel calls a "linear" address) w= ithout a check that the pagetables enable userspace access. The check happe= ns after the speculative execution of the memory access.=0A =0AI repeat thi= s, because many pseudo-experts who love to be quoted in the press as saying= "be afraid, be very afraid" are saying a lot of nonsense about Meltdown an= d Sceptre. It seems to be an echo chamber effect - the papers were released= yesterday afternoon, but in a rush to get "quoted", all the wannabe-quoted= people are saying things that are just plain NOT TRUE.=0A =0A =0A-----Orig= inal Message-----=0AFrom: "Joel Wir=C4=81mu Pauling" <[ joel@aenertia.net ]= ( mailto:joel@aenertia.net )>=0ASent: Thursday, January 4, 2018 4:44pm=0ATo= : "Jonathan Morton" <[ chromatix99@gmail.com ]( mailto:chromatix99@gmail.co= m )>=0ACc: [ cerowrt-devel@lists.bufferbloat.net ]( mailto:cerowrt-devel@li= sts.bufferbloat.net )=0ASubject: Re: [Cerowrt-devel] KASLR: Do we have to w= orry about other arches than x86?=0A=0A=0A=0A=0A=0A=0A=0A=0AOn 5 January 20= 18 at 01:09, Jonathan Morton <[ chromatix99@gmail.com ]( mailto:chromatix99= @gmail.com )> wrote:=0A=0A=0A I don't think we need to worry about it too m= uch in a router context. Virtual server folks, OTOH...=0A=0A=0A=0A - Jona= than Morton=0A=0A=0A=0A=E2=80=8BDisagree - The Router is pretty much synony= mous with NFV=E2=80=8B =0A=E2=80=8B; I run my lede instances at home on hyp= ervisors - and this is definitely the norm in Datacentres now. We need to w= ork through this quite carefully. =E2=80=8B ------=_20180104170919000000_74965 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I don't disagree that = anyone who can run code in the hypervisor itself can attack the guest insta= nces.

=0A

 

=0A

But that= has nothing to do with KALSR or Meltdown or Sceptre. That's just bad secur= ity design - the rule is "the principle of least privilege", which comes fr= om the 1970's work on secure operating systems.

=0A

=  

=0A

I should point out here that I was one of= the researchers that helped develop the original multi-level security syst= ems then. Those "colored books" come from us.

=0A

&n= bsp;

=0A

-----Original Message-----
From: "Joel= Wir=C4=81mu Pauling" <joel@aenertia.net>
Sent: Thursday, Januar= y 4, 2018 5:00pm
To: "dpreed@deepplum.com" <dpreed@deepplum.com>=
Cc: "Jonathan Morton" <chromatix99@gmail.com>, cerowrt-devel@li= sts.bufferbloat.net
Subject: Re: [Cerowrt-devel] KASLR: Do we have to = worry about other arches than x86?

=0A
=0A
=0A
SRIOV ports and Vendor NIC optimizations wrt= Latencies.

=0A
Whilst these heavy hitting NVF appliances tend= to be large and span multiple compute hosts (and therefore are the only te= nannts on those computes) - this isn't always the case.

= =0A
= It's a problem in that if you can get onto the hypervisor even as an unpriv= ileged user you can read out guest stores. .... Big Problem.
=0A=0A

=0A
On 5 Jan= uary 2018 at 10:57, dpreed@deepplum.= com <dpreed@deepplum.com> wrote:
=0A
=0A

Hmm... protection datacentres t= end to require lower latencies than can be achieved running on hypervisors.=

=0A

 

=0A

Which doesn't mean th= at some datacenters don't do that.

=0A

 

=0A

As far as NFV is concerned, Meltdown only breaks security if a= userspace application is running on a machine where another user has data = running through kernel address space. NFV environments don't tend to run NF= V in userspace under an OS that has kernel data in the page tables that are= reachable from CR3.

=0A

 

=0A

T= he key issue in Meltdown is that CR3 is not changed between userspace and k= ernelspace. Which means that the memory access pipeline in userspace can us= e a kernelspace address (what Intel calls a "linear" address) without a che= ck that the pagetables enable userspace access. The check happens after the= speculative execution of the memory access.

=0A

 <= /p>=0A

I repeat this, because many pseudo-experts who love = to be quoted in the press as saying "be afraid, be very afraid" are saying = a lot of nonsense about Meltdown and Sceptre. It seems to be an echo chambe= r effect - the papers were released yesterday afternoon, but in a rush to g= et "quoted", all the wannabe-quoted people are saying things that are just = plain NOT TRUE.

=0A

 

=0A

 =

=0A

-----Original Message-----
From: "Joel Wir=C4= =81mu Pauling" <j= oel@aenertia.net>
Sent: Thursday, January 4, 2018 4:44pm
T= o: "Jonathan Morton" <chromatix99@gmail.com>
Cc: cerowrt-devel@lists.bufferblo= at.net
Subject: Re: [Cerowrt-devel] KASLR: Do we have to worry abo= ut other arches than x86?

=0A
=0A
=0A=0A
=0A=

=0A
On 5 January= 2018 at 01:09, Jonathan Morton <chromatix99@gmail.com> = wrote:
=0A


I don't th= ink we need to worry about it too much in a router context.  Virtual s= erver folks, OTOH...
=0A
=0A=

 - Jonathan Morton
=
=0A
=0A
=0A
=0A
=E2=80=8BDisa= gree - The Router is pretty much synonymous with NFV=E2=80=8B
=0A = ;=0A
=E2=80=8B; I run my lede instances at home on hypervisors= - and this is definitely the norm in Datacentres now. We need to work thro= ugh this quite carefully. =E2=80=8B
=0A
=0A
=0A
=0A=0A
=0A
=0A
=0A
=0A
=0A
=0A
------=_20180104170919000000_74965--