<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">If you are using name-spaces to provide a level of context separation between your processes ... it's a problem. <br><br><br><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 5 January 2018 at 10:59, <a href="mailto:dpreed@deepplum.com">dpreed@deepplum.com</a> <span dir="ltr"><<a href="mailto:dpreed@deepplum.com" target="_blank">dpreed@deepplum.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font face="arial" size="2"><p style="margin:0;padding:0;font-family:arial;font-size:10pt">Containers and kernel namespaces, and so forth are MEANINGLESS against the Meltdown and Sceptre problems. It's a hardware bug that lets any userspace process access anything the kernel can address.</p>
<p style="margin:0;padding:0;font-family:arial;font-size:10pt"> </p>
<p style="margin:0;padding:0;font-family:arial;font-size:10pt"><span class="">-----Original Message-----<br>From: "Joel Wirāmu Pauling" <<a href="mailto:joel@aenertia.net" target="_blank">joel@aenertia.net</a>><br></span><span class="">Sent: Thursday, January 4, 2018 4:52pm<br>To: "Dave Taht" <<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>><br>Cc: "Jonathan Morton" <<a href="mailto:chromatix99@gmail.com" target="_blank">chromatix99@gmail.com</a>>, <a href="mailto:cerowrt-devel@lists.bufferbloat.net" target="_blank">cerowrt-devel@lists.<wbr>bufferbloat.net</a><br>Subject: Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?<br><br></span></p><div><div class="h5">
<div id="m_8851240597799122506SafeStyles1515103096">
<div dir="ltr">
<div class="gmail_default" style="font-family:verdana,sans-serif">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.<br><br></div>
<div class="gmail_default" style="font-family:verdana,sans-serif">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.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 5 January 2018 at 10:47, Dave Taht <span dir="ltr"><<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="m_8851240597799122506HOEnZb">
<div class="m_8851240597799122506h5">On Thu, Jan 4, 2018 at 1:44 PM, Joel Wirāmu Pauling <<a href="mailto:joel@aenertia.net" target="_blank">joel@aenertia.net</a>> wrote:<br> ><br> ><br> > On 5 January 2018 at 01:09, Jonathan Morton <<a href="mailto:chromatix99@gmail.com" target="_blank">chromatix99@gmail.com</a>> wrote:<br> >><br> >><br> >><br> >> I don't think we need to worry about it too much in a router context.<br> >> Virtual server folks, OTOH...<br> >><br> >>  - Jonathan Morton<br> >><br> > Disagree - The Router is pretty much synonymous with NFV<br> ><br> > ; I run my lede instances at home on hypervisors - and this is definitely<br> > the norm in Datacentres now. We need to work through this quite carefully.<br><br></div>
</div>
Yes, the NFV case is serious and what I concluded we had most to worry<br> about - before starting to worry about the lower end router chips<br> themselves. But I wasn't aware that people were actually trying to run<br> lede in that, I'd kind of expected<br> a more server-like distro to be used there. Why lede in a NFV? Ease of<br> configuration? Reduced attack surface? (hah)<br><br> The only x86 chip I use (aside from simulations) is the AMD one in the<br> apu2, which I don't know enough about as per speculation...<br>
<div class="m_8851240597799122506HOEnZb">
<div class="m_8851240597799122506h5"><br> --<br><br> Dave Täht<br> CEO, TekLibre, LLC<br><a rel="noreferrer" href="http://www.teklibre.com" target="_blank">http://www.teklibre.com</a><br> Tel: 1-669-226-2619</div>
</div>
</blockquote>
</div>
</div>
</div></div></div></font></blockquote></div><br></div>