From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 295C13B2A4 for ; Thu, 4 Jan 2018 17:13:54 -0500 (EST) Received: by mail-yw0-x22d.google.com with SMTP id f1so1124412ywd.8 for ; Thu, 04 Jan 2018 14:13:54 -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=GmbanaP1lkhHakewbH+J1+KaYIdvQlq3B2raRWoyNb0=; b=CzLxU64h+/zJl1RsAHg0ivvTFwAfrE4ozxxtdLheWRZA7lwSWDns6W89DTVligFO// CIubfx2LQYI062Hun6gfAEOuHoitda6T2vhrpw/GQoC0o0B166wOTYMt/4HDvnDzDMZH Pq3SPgJ/PAdiX6zX5LRl5SY83cRcLyuseT6s4= 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=GmbanaP1lkhHakewbH+J1+KaYIdvQlq3B2raRWoyNb0=; b=LhWn6F5zIN70BvWT6FeCsPYG+T6kjTzljvP3HC0CDssAOksqQg7Nv3V/zRavG4VHSN +GW4ybl9Swx3vkZFaUv6xNZFJyewtbQBow+HMCCiF6HrqvJk4WDJACijGqqT6cZwtOoX vwH436ztOHD6ccqdyOrqGmWAbz7acH/7Vx1roHIrTGXeNzpw3DkMfQ+15vDrgrMkY0rq 6JPdsjyBPuNSgTM1uXxEnjL6EraJ1XMdJZhEWsf90KAsKrC2TleJ9xVzd/avE81WPI+G mapcTr26HcHfzSQVoKklBQR41fWBqgHzm7U6RrhKacnAzL0nKO/VjdUDeEW1+AYdBpLn j/SQ== X-Gm-Message-State: AKGB3mL9HknjxG4NCXGcP0moJAPYar4AaOua9SyAMQxE1smNasbTHeON Hb9cQNpGrGw3HMYyqnZ5ORxBfGoLvwdRIMr5xNmgEQ== X-Google-Smtp-Source: ACJfBotcn0fJP4WTnHkERoTcCyPplznl5MmawOmqvwUS7TLoMqtDby9zJD1ESfXrHQ4aSdflQghswYMOHAZvA1zWOr0= X-Received: by 10.129.87.73 with SMTP id l70mr942478ywb.342.1515104033287; Thu, 04 Jan 2018 14:13:53 -0800 (PST) MIME-Version: 1.0 Sender: aenertia@aenertia.net Received: by 10.37.132.135 with HTTP; Thu, 4 Jan 2018 14:13:32 -0800 (PST) In-Reply-To: <1515103759.340132151@apps.rackspace.com> References: <1515103048.715224709@apps.rackspace.com> <1515103759.340132151@apps.rackspace.com> From: =?UTF-8?Q?Joel_Wir=C4=81mu_Pauling?= Date: Fri, 5 Jan 2018 11:13:32 +1300 X-Google-Sender-Auth: M7slIK6QnExtZcmQUL4DTEu_AbM Message-ID: To: "dpreed@deepplum.com" Cc: Jonathan Morton , cerowrt-devel@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="001a113a8b6cb3c9780561faa5ad" 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:13:54 -0000 --001a113a8b6cb3c9780561faa5ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Talking cross purposes here ; I am merely pointing out WHY it's a problem in the routing world. I also have coloured books from my past, they mostly involve bad 80's Children's TV series tie ins and 'between the lines' style instructions. -Joel On 5 January 2018 at 11:09, dpreed@deepplum.com wrote= : > I don't disagree that anyone who can run code in the hypervisor itself ca= n > attack the guest instances. > > > > But 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", whi= ch > comes from the 1970's work on secure operating systems. > > > > I should point out here that I was one of the researchers that helped > develop the original multi-level security systems then. Those "colored > books" come from us. > > > > -----Original Message----- > From: "Joel Wir=C4=81mu Pauling" > Sent: Thursday, January 4, 2018 5:00pm > To: "dpreed@deepplum.com" > Cc: "Jonathan Morton" , cerowrt-devel@lists. > bufferbloat.net > Subject: Re: [Cerowrt-devel] KASLR: Do we have to worry about other arche= s > than x86? > > 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 b= e >> 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 >> and kernelspace. Which means that the memory access pipeline in userspac= e >> can use a kernelspace address (what Intel calls a "linear" address) with= out >> a check that the pagetables enable userspace access. The check happens >> after 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 >> arches 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 >> definitely the norm in Datacentres now. We need to work through this qui= te >> carefully. =E2=80=8B >> > --001a113a8b6cb3c9780561faa5ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Talking cross purposes here ; I am merely pointing out WHY it&#= 39;s a problem in the routing world.

I also have coloured books fro= m my past, they mostly involve bad 80's Children's TV series tie in= s and 'between the lines' style instructions.

-Joel

On 5 Janu= ary 2018 at 11:09, dpreed@deepplum.c= om <dpreed@deepplum.com> wrote:

I don't disagree that anyone who ca= n run code in the hypervisor itself can attack the guest instances.

=C2=A0

But that h= as nothing to do with KALSR or Meltdown or Sceptre. That's just bad sec= urity design - the rule is "the principle of least privilege", wh= ich comes from the 1970's work on secure operating systems.

=C2=A0

I should p= oint out here that I was one of the researchers that helped develop the ori= ginal multi-level security systems then. Those "colored books" co= me from us.

=C2=A0

-----Original Message-----
From: "Joel Wir=C4=81mu Pauling&q= uot; <joel@aenert= ia.net>

SRIOV= ports and Vendor NIC optimizations wrt Latencies.

Whils= t these heavy hitting NVF appliances tend to be large and span multiple com= pute hosts (and therefore are the only tenannts on those computes) - this i= sn't always the case.

It= 9;s a problem in that if you can get onto the hypervisor even as an unprivi= leged user you can read out guest stores. .... Big Problem.

On 5 January 2018 at 10:57, dpreed@deepplum.com <dpreed@dee= pplum.com> wrote:

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

=C2=A0

Which doesn't mean that some datacenters don't do that.

=C2=A0

As far as NFV is concerned, Meltdown only breaks security if a use= rspace application is running on a machine where another user has data runn= ing 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.

=C2=A0

The key issue in Meltdown is that CR3 is not changed between users= pace and kernelspace. Which means that the memory access pipeline in usersp= ace can use a kernelspace address (what Intel calls a "linear" ad= dress) without a check that the pagetables enable userspace access. The che= ck happens after the speculative execution of the memory access.

=C2=A0

I repeat this, because many pseudo-experts who love to be quoted i= n the press as saying "be afraid, be very afraid" are saying a lo= t of nonsense about Meltdown and Sceptre. It seems to be an echo chamber ef= fect - the papers were released yesterday afternoon, but in a rush to get &= quot;quoted", all the wannabe-quoted people are saying things that are= just plain NOT TRUE.

=C2=A0

=C2=A0

-----Original Message-----
From: "Joel Wir=C4=81mu Pauling= " <joel@aene= rtia.net>
Sent: Thursday, January 4, 2018 4:44pm
To: "Jon= athan Morton" <chromatix99@gmail.com>
Cc: cerowrt-devel@lists.bufferbl= oat.net
Subject: Re: [Cerowrt-devel] KASLR: Do we have to worry abou= t other arches than 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- Jo= nathan 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

--001a113a8b6cb3c9780561faa5ad--