Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

4, 2018 9:53am 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 Thu, Jan 4, 2018 at 6:49 AM, Jonathan Morton wrote: >> On 4 Jan, 2018, at 3:59 pm, Dave Taht wrote: >>

Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

I was too busy skateboarding holding on to the bumper of my Limo to take notice obviously. On 5 January 2018 at 11:26, Jonathan Morton wrote: > > On 5 Jan, 2018, at 12:09 am, dpr...@deepplum.com wrote: > > > > I should point out here that I was one of the researchers that

Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

> On 5 Jan, 2018, at 12:09 am, dpr...@deepplum.com wrote: > > 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. Obligatory: https://www.youtube.com/watch?v=4U9MI0u2VIE -

Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

t;Joel Wirāmu Pauling" <j...@aenertia.net> > > Sent: Thursday, January 4, 2018 5:00pm > To: "dpr...@deepplum.com" <dpr...@deepplum.com> > Cc: "Jonathan Morton" <chromati...@gmail.com>, > cerowrt-devel@lists.bufferbloat.net > Subject: Re

Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

> > > > -Original Message- > From: "Joel Wirāmu Pauling" <j...@aenertia.net> > Sent: Thursday, January 4, 2018 5:00pm > To: "dpr...@deepplum.com" <dpr...@deepplum.com> > Cc: "Jonathan Morton" <chromati...@gmail.com>, cer

Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

chromati...@gmail.com>, cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86? On Thu, Jan 4, 2018 at 2:02 PM, dpr...@deepplum.com <dpr...@deepplum.com> wrote: > Containers and kernel namespaces, and so forth are MEANING

Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

nt: Thursday, January 4, 2018 5:00pm To: "dpr...@deepplum.com" <dpr...@deepplum.com> Cc: "Jonathan Morton" <chromati...@gmail.com>, cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86? SRIOV po

Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

ot; <j...@aenertia.net> > Sent: Thursday, January 4, 2018 4:52pm > To: "Dave Taht" <dave.t...@gmail.com> > Cc: "Jonathan Morton" <chromati...@gmail.com>, > cerowrt-devel@lists.bufferbloat.net > Subject: Re: [Cerowrt-devel] KASLR: Do we have to wor

Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

; Sent: Thursday, January 4, 2018 4:52pm To: "Dave Taht" <dave.t...@gmail.com> Cc: "Jonathan Morton" <chromati...@gmail.com>, cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86? Well as I've argu

Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

ing things that are just plain NOT TRUE. -Original Message- From: "Joel Wirāmu Pauling" <j...@aenertia.net> Sent: Thursday, January 4, 2018 4:44pm To: "Jonathan Morton" <chromati...@gmail.com> Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-

Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

hat are just plain NOT > TRUE. > > > > > > -Original Message- > From: "Joel Wirāmu Pauling" <j...@aenertia.net> > Sent: Thursday, January 4, 2018 4:44pm > To: "Jonathan Morton" <chromati...@gmail.com> > Cc: cerowrt-devel

Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

Yup - and I know of more than one SDN ISP that is using Lede as their CPE VNF - straight off the x86 build servers. Whilst it's more a Hyper-visor mitigation there are certainly things guest can do to improve situation. But yes we should look at both cases in detail. On 5 January 2018 at 10:54,

Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

On Thu, Jan 4, 2018 at 1:52 PM, Joel Wirāmu Pauling wrote: > 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. Enough stuff landed in the last kernel for me

Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

On Thu, 04 Jan 2018 13:40:28 -0800, Dave Taht said: > I guess I'm hoping for simple patches to the microcode to arrive next > week, even simply stuff to disable the branch predictor or speculative > execution, something simple, slow, and sane. In my inbox this morning. I have *no* idea why Intel

Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

2018 9:53am > To: "Jonathan Morton" <chromati...@gmail.com> > Cc: cerowrt-devel@lists.bufferbloat.net > Subject: Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches > than x86? > > On Thu, Jan 4, 2018 at 6:49 AM, Jonathan Morton <chromati...@gmail.com>

Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

On Thu, Jan 4, 2018 at 6:49 AM, Jonathan Morton wrote: >> On 4 Jan, 2018, at 3:59 pm, Dave Taht wrote: >> >> Alan cox has been doing a good job of finding the good stuff. Power >> and the IBM z-series are also affected. > > Conversely, the ARM-1176,

Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

> On 4 Jan, 2018, at 3:59 pm, Dave Taht wrote: > > Alan cox has been doing a good job of finding the good stuff. Power > and the IBM z-series are also affected. Conversely, the ARM-1176, Cortex-A7 and Cortex-A53 cores used by various iterations of the Raspberry Pi are not

Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

Alan cox has been doing a good job of finding the good stuff. Power and the IBM z-series are also affected. https://plus.google.com/u/0/+AlanCoxLinux On Thu, Jan 4, 2018 at 5:48 AM, Jonathan Morton wrote: > > >> On 4 Jan, 2018, at 3:38 pm, Dave Taht

Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

> On 4 Jan, 2018, at 3:38 pm, Dave Taht wrote: > > I lay awake last night trying to figure out what the impact of these > bugs would be on the market. What I think will happen is everybody's > stock is going to go up as there is a mad rush to replace now 10-30% > slower

Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

On Thu, Jan 4, 2018 at 4:09 AM, Jonathan Morton wrote: > Okay, it's a little bit more nuanced than I thought. In fact there are > *three* different CPU hardware vulnerabilities just disclosed. I've > summarised the impact in this Reddit post: > >

Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

Okay, it's a little bit more nuanced than I thought. In fact there are *three* different CPU hardware vulnerabilities just disclosed. I've summarised the impact in this Reddit post: https://www.reddit.com/r/Amd/comments/7o2i91/technical_analysis_of_spectre_meltdown/ The TL;DR version is: -

Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

As I thought: https://lkml.org/lkml/2017/12/27/2 "AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher

Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

It looks nasty, but if it's a hardware bug then it's likely applicable only to specific CPUs. - Jonathan Morton ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

or is this primarily a virtualization bug? http://hn.premii.com/#/article/16046636 "Bad news: the software mitigation is expensive The primary reason for the old Linux behaviour of mapping kernel memory in the same page tables as user memory is so that when the user’s code triggers a system