From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb0-x243.google.com (mail-yb0-x243.google.com [IPv6:2607:f8b0:4002:c09::243]) (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 B69C23B2A4 for ; Thu, 4 Jan 2018 16:52:42 -0500 (EST) Received: by mail-yb0-x243.google.com with SMTP id f16so1184943ybn.0 for ; Thu, 04 Jan 2018 13:52:42 -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=jxzk7FMumN6X/ZrmqZfs8YHAiuw8S161y+1ihF/i3pg=; b=CcdkNIEw0q5FNjryiUSSpmVhkpkk+S/KqGuGTo0PRwuwwEre5STkiObvOGbZaqdFrg DfXQmphY9Fbk7/mAc/x7YYkklwX8s4PgLVXqTKD7iucDp/JsczLmvKkjvc7fYNz3ScI1 g91/wgG1DmkErC9d6DywwolPOG+jzd0VDQOls= 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=jxzk7FMumN6X/ZrmqZfs8YHAiuw8S161y+1ihF/i3pg=; b=TQPRgmawfjdZne6zCOisA0hpiJSGuzs0M6+faFI9AY0Z97BxD8+K4P2P4qhV66vdQS 6k4qitaIUjCPmDU9LQA8tbPDTHWRDjD7vOKrerkDr1U47MlXw2bfPUtQZENyfa+3AGQj ZxzfzVzMo3RIkJo8+oamAEfGEtM9UIKhLLTSfRIDT0BYs2i1RZzuc8crwH5tYNub9HoF edK+LN9RD3J66N5Z1xm0G6G/MsUDhKikkgMqj/nFZ4fOoSQzgBnvQHHoKJrMK/x6YmFt LUefGXS5OLIYWpbzFKGwcvZ7TdHNaCV43wPJ2/JVUFqvQTjcjMwbs+hAL9YBWU7n2BeX +9ZQ== X-Gm-Message-State: AKGB3mIEzksTIqnI383+bFOpHAgSm2nV28IMIifddsXY2Ls7jrWw+D92 Kr1Pn6VYtyPmt6IGw+kK1ZyrYpRyKah7MhhgBvbdMg== X-Google-Smtp-Source: ACJfBos6CveKEYAZgnwqgdjVCpgqIetIir2mFlo5WNtZgczhsZjgXNGLojGFFb+H914BDLMAzY2XEz2OeVAgDGOqlP8= X-Received: by 10.37.135.73 with SMTP id e9mr993194ybn.518.1515102762104; Thu, 04 Jan 2018 13:52:42 -0800 (PST) MIME-Version: 1.0 Sender: aenertia@aenertia.net Received: by 10.37.132.135 with HTTP; Thu, 4 Jan 2018 13:52:21 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?Joel_Wir=C4=81mu_Pauling?= Date: Fri, 5 Jan 2018 10:52:21 +1300 X-Google-Sender-Auth: kLLichqjAqKQOIcq0Bke3i-rea4 Message-ID: To: Dave Taht Cc: Jonathan Morton , cerowrt-devel@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="089e08289770ef10e20561fa5910" 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 21:52:42 -0000 --089e08289770ef10e20561fa5910 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Well as I've argued before Lede ideally should be using to Kernel Namespaces (poor mans containers) for at a minimum the firewall and per-interface routing instances. The stuff I am running at home is mostly on cheap Atom board, so it's a matter of squeezing out unneeded cruft on the platform. Also I don't want to be admining centos/rhel servers at home. On 5 January 2018 at 10:47, Dave Taht wrote: > On Thu, Jan 4, 2018 at 1:44 PM, Joel Wir=C4=81mu Pauling > wrote: > > > > > > 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 > >> > > Disagree - The Router is pretty much synonymous with NFV > > > > ; I run my lede instances at home on hypervisors - and this is definite= ly > > the norm in Datacentres now. We need to work through this quite > carefully. > > Yes, the NFV case is serious and what I concluded we had most to worry > about - before starting to worry about the lower end router chips > themselves. But I wasn't aware that people were actually trying to run > lede in that, I'd kind of expected > a more server-like distro to be used there. Why lede in a NFV? Ease of > configuration? Reduced attack surface? (hah) > > The only x86 chip I use (aside from simulations) is the AMD one in the > apu2, which I don't know enough about as per speculation... > > -- > > Dave T=C3=A4ht > CEO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-669-226-2619 > --089e08289770ef10e20561fa5910 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Well as I've argued before Lede ideally should be using to = Kernel Namespaces (poor mans containers) for at a minimum the firewall and = per-interface routing instances.

The stuff I am running at home is = mostly on cheap Atom board, so it's a matter of squeezing out unneeded = cruft on the platform. Also I don't want to be admining centos/rhel ser= vers at home.

On 5 January 2018 at 10:47, Dave Taht <dave.taht@gmail.com> wrote:
On Thu, Jan 4, 2018 at 1:44 PM, Joel Wir=C4=81mu Paulin= g <joel@aenertia.net> wrote:=
>
>
> 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 c= ontext.
>> Virtual server folks, OTOH...
>>
>>=C2=A0 - Jonathan Morton
>>
> Disagree - The Router is pretty much synonymous with NFV
>
> ; I run my lede instances at home on hypervisors - and this is definit= ely
> the norm in Datacentres now. We need to work through this quite carefu= lly.

Yes, the NFV case is serious and what I concluded we had most t= o worry
about - before starting to worry about the lower end router chips
themselves. But I wasn't aware that people were actually trying to run<= br> lede in that, I'd kind of expected
a more server-like distro to be used there. Why lede in a NFV? Ease of
configuration? Reduced attack surface? (hah)

The only x86 chip I use (aside from simulations) is the AMD one in the
apu2, which I don't know enough about as per speculation...

--

Dave T=C3=A4ht
CEO, TekLibre, LLC
ht= tp://www.teklibre.com
Tel: 1-669-226-2619

--089e08289770ef10e20561fa5910--