From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (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 C5D113B2A4 for ; Thu, 4 Jan 2018 17:00:57 -0500 (EST) Received: by mail-yb0-x233.google.com with SMTP id k189so1185223ybc.12 for ; Thu, 04 Jan 2018 14:00:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aenertia.net; s=dkimaenertianet; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=5/4q5OQpCMo02UIRIn2WS5uVjx5EKAVR2VG9l6X2a98=; b=diu/K7Z7bdKrywDCjRAp185GUBGgF2FLQLRjsgs2mfpOSKQ5tN3S1jvu7+hNIwwwzk OT6CBY9vgHyYwAX/QTyQWqfkKN5lSOrvfrX8u3NhiDJFqxKPR7SG5F/uONutx7AWFgm2 p/D/nlWkuLnSxD9GMHpuvW9TUe61M5GE/2M2Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=5/4q5OQpCMo02UIRIn2WS5uVjx5EKAVR2VG9l6X2a98=; b=iV5WwjqP/WrsBR2V5HBfJLZvrc+VHF3ljWDPzYxWWzQ/+c9AUxEZybpKptL4YDGRsi XJqdA73SWD99xVClTmevf63nNgFDwfgoX5EekH9mBty6iOaQSwT5PFIsxcuroBCTnBsL YeSc+y88JSNQbVSY4ka9rO7L+AEqFCmpw0e10tOkCMgdawBqn/r7V/ry9NZxPV/7QmBx ccjiL8YxOUeCf/yLdRGuxtbFWYOkyq392Nn/y6nBSGID9EbYAqwAfoCbkQr0LKpMuwkI J+JN3nfuZA6GIPj33fD8zRmUhYOaMlWEwjLnzC2QzRvroHEjBCvpGo4vIAs1q8MRA6qB KZ5w== X-Gm-Message-State: AKGB3mJRAghFqr4Y489vB+wZqUrPz2ZpN+gqMK8HdmfXKF2tKU0TL0Kr K7zpqMNnSuMk3aBH6kQHqj9IYCgptGQqlPz2HN38qQ== X-Google-Smtp-Source: ACJfBosC/LbttOjzggo6eiwqJB7pWcIXGZ4khRS35Kcu21Cw1NCX0/nsmhozDTbPf4ogTRm6M/73VlHIbrmrHYeQgaE= X-Received: by 10.37.9.66 with SMTP id u2mr970077ybm.379.1515103257156; Thu, 04 Jan 2018 14:00:57 -0800 (PST) MIME-Version: 1.0 Sender: aenertia@aenertia.net Received: by 10.37.132.135 with HTTP; Thu, 4 Jan 2018 14:00:36 -0800 (PST) In-Reply-To: <1515103048.715224709@apps.rackspace.com> References: <1515103048.715224709@apps.rackspace.com> From: =?UTF-8?Q?Joel_Wir=C4=81mu_Pauling?= Date: Fri, 5 Jan 2018 11:00:36 +1300 X-Google-Sender-Auth: krOurrumqgsjEPf0EPEsOpNxbBc Message-ID: To: "dpreed@deepplum.com" Cc: Jonathan Morton , cerowrt-devel@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="f403043bdad470f1d20561fa7780" 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 22:00:57 -0000 --f403043bdad470f1d20561fa7780 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable SRIOV ports and Vendor NIC optimizations wrt Latencies. Whilst these heavy hitting NVF appliances tend to be large and span multiple compute hosts (and therefore are the only tenannts on those computes) - this isn't always the case. It's a problem in that if you can get onto the hypervisor even as an unprivileged user you can read out guest stores. .... Big Problem. On 5 January 2018 at 10:57, dpreed@deepplum.com wrote= : > Hmm... protection datacentres tend to require lower latencies than can be > achieved running on hypervisors. > > > > Which doesn't mean that some datacenters don't do that. > > > > 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 NFV in > userspace under an OS that has kernel data in the page tables that are > reachable from CR3. > > > > The key issue in Meltdown is that CR3 is not changed between userspace an= d > kernelspace. Which means that the memory access pipeline in userspace can > use a kernelspace address (what Intel calls a "linear" address) without a > check that the pagetables enable userspace access. The check happens afte= r > the speculative execution of the memory access. > > > > 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 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. > > > > > > -----Original Message----- > From: "Joel Wir=C4=81mu Pauling" > Sent: Thursday, January 4, 2018 4:44pm > To: "Jonathan Morton" > Cc: cerowrt-devel@lists.bufferbloat.net > Subject: Re: [Cerowrt-devel] KASLR: Do we have to worry about other arche= s > than x86? > > > On 5 January 2018 at 01:09, Jonathan Morton wrote= : > >> >> >> I don't think we need to worry about it too much in a router context. >> Virtual server folks, OTOH... >> >> - Jonathan Morton >> >> =E2=80=8BDisagree - The Router is pretty much synonymous with NFV=E2=80= =8B > > =E2=80=8B; I run my lede instances at home on hypervisors - and this is d= efinitely > the norm in Datacentres now. We need to work through this quite carefully= . =E2=80=8B > --f403043bdad470f1d20561fa7780 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
SRIOV ports and Vendor NIC optimizations wrt Latencies.

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

It's a problem in that if you = can get onto the hypervisor even as an unprivileged user you can read out g= uest stores. .... Big Problem.
<= br>
On 5 January 2018 at 10:57, dpreed@deepplum.com <dpreed@deepplum.com&g= t; wrote:

Hm= m... protection datacentres tend to require lower latencies than can be ach= ieved running on hypervisors.

=C2=A0

Which does= n't mean that some datacenters don't do that.

=C2=A0

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 NFV in userspace unde= r an OS that has kernel data in the page tables that are reachable from CR3= .

=C2=A0

The key is= sue in Meltdown is that CR3 is not changed between userspace and kernelspac= e. Which means that the memory access pipeline in userspace can use a kerne= lspace address (what Intel calls a "linear" address) without a ch= eck that the pagetables enable userspace access. The check happens after th= e speculative execution of the memory access.

=C2=A0

I repeat t= his, because many pseudo-experts who love to be quoted in the press as sayi= ng "be afraid, be very afraid" are saying a lot of nonsense about= Meltdown and Sceptre. It seems to be an echo chamber effect - the papers w= ere released yesterday afternoon, but in a rush to get "quoted", = all the wannabe-quoted people are saying things that are just plain NOT TRU= E.

=C2=A0

=C2=A0

-----Origi= nal Message-----
From: "Joel Wir=C4=81mu Pauling" <joel@aenertia.net>Sent: Thursday, January 4, 2018 4:44pm
To: "Jonathan Morton"= <chromatix99= @gmail.com>
Cc: cerowrt-devel@lists.bufferbloat.net
Sub= ject: Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches tha= n x86?


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


I don't think we need to worry = about it too much in a router context.=C2=A0 Virtual server folks, OTOH...<= br>

=C2=A0- Jonathan Morton

=
=E2=80=8BDisagree - The Router is pretty much synonymous with NFV= =E2=80=8B
=C2=A0
=E2=80=8B; I run my lede instances at home on hypervisors - and t= his is definitely the norm in Datacentres now. We need to work through this= quite carefully. =E2=80=8B

--f403043bdad470f1d20561fa7780--