Re: [Cerowrt-devel] Spectre and EBPF JIT

2018-01-04 Thread Dave Taht 
It took me a long while to digest that one. The branch predictor
analysis of haswell was easiest to understand (and AMD claims to have
an AI based one), and perhaps scrambling that at random intervals
would help? (this stuff is now way above my pay grade)
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] Spectre and EBPF JIT

2018-01-04 Thread dpr...@deepplum.com 

As I continue to study the Spectre bug, I read the Project Zero post about 
POC's they developed for Spectre.
 
[ 
https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
 ]( 
https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
 )
 
(the Meltdown and Spectre papers, linked from that page are far better at 
explaining the mechanics of the issue. Read Meltdown first, it's simpler.).
 
It was very enlightening to see that one exploit used the "in-kernel eBPF JIT 
interpreter". This one also looks very practical to exploit, and it is "network 
related" so of some interest here.  The Project Zero post doesn't describe the 
exploit itself, but reading the Spectre paper gives one context on how Spectre 
works.
 
Unlike Meltdown, Spectre really depends on the attacker being able to force 
certain instruction sequences to get executed in some address space, such that 
the effect can be observed in another address space where the attacker's 
observer resides.
 
What this means is that to read data from the kernel, Spectre needs to force a 
specific code sequence to be executed, with a branch mispredicted, *in the 
kernel*.
 
That's where the eBPF JIT comes into play, apparently. Because the eBPF JIT 
allows *kernel code* to be constructed from the attackers userspace code. 
Hmmm... sounds like the user can change the kernel binary code and get it 
executed!
 
So this is a relatively practical thing to do, and it gives full access to 
anything in the kernel address space, from a userspace program.
 
Now it's easy to disable the JIT feature. Just a packet processing performance 
hit.
 
But I bet designing the JIT so it won't generate Spectre-exploitable code would 
be tricky indeed.
 
Especially since the Spectre-exploitable code is highly processor architecture 
specific, unlike Meltdown, which appears to be Intel-only.___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] bufferbloat.net prep

2018-01-04 Thread Dave Taht 
Most of the bufferbloat.net servers are on linode. They are planning a
fleet-wide reboot:

https://blog.linode.com/2018/01/03/cpu-vulnerabilities-meltdown-spectre/

'Course this doesn't help as much as you'd like if one or more of your
servers is already compromised, and had keys or shared passwords. So -
sigh - theoretically I'm on vacation - I'm planning on revoking those
keys, and rebuilding others from scratch.

I might, like other big providers do, end up building my own cloudy
kernels again.

There's only one server I seriously care about the security of in the
cloud, the vpn server. Maybe it's time to truly decentralize the vpn
this time around. I think of how exposed others must be, and shudder.

"If your provider does not have a fix then now is a good time to
practice that recovery plan you should have for what to do when your
cloud provider goes down." - Alan Cox

https://plus.google.com/+AlanCoxLinux/posts/Z6inLSq4iqH


On Thu, Jan 4, 2018 at 2:35 PM, Joel Wirāmu Pauling  wrote:
> 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 helped
>> > develop the original multi-level security systems then. Those "colored
>> > books" come from us.
>>
>> Obligatory:  https://www.youtube.com/watch?v=4U9MI0u2VIE
>>
>>  - Jonathan Morton
>>
>
>
> ___
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

2018-01-04 Thread Joel Wirāmu Pauling 
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 helped
> develop the original multi-level security systems then. Those "colored
> books" come from us.
>
> Obligatory:  https://www.youtube.com/watch?v=4U9MI0u2VIE
>
>  - Jonathan Morton
>
>
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

2018-01-04 Thread Jonathan Morton 
> 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

 - Jonathan Morton

___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

2018-01-04 Thread Dave Taht 
On Thu, Jan 4, 2018 at 2:09 PM, dpr...@deepplum.com  wrote:
> I don't disagree that anyone who can run code in the hypervisor itself can
> 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", which
> 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.

You are one of the few remaining that have written those. Back when I
read those (in 1990 or so,
SCO was trying for at least a c1 rating), I felt they were impossible
to implement without hardware support,
which led to my early interest in capabilities based architectures.
Sadly the need for speed trumped all security concerns in the decades
since.

There are undoubtably sordid tales we both could tell here.

https://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria
>
>
> -Original Message-
> From: "Joel Wirāmu Pauling" 
>
> Sent: Thursday, January 4, 2018 5:00pm
> To: "dpr...@deepplum.com" 
> Cc: "Jonathan Morton" ,
> cerowrt-devel@lists.bufferbloat.net
> Subject: Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches
> 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, dpr...@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 and
>> 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 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āmu 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
>>>
>> Disagree - The Router is pretty much synonymous with NFV
>>
>> ; I run my lede instances at home on hypervisors - and this is definitely
>> the norm in Datacentres now. We need to work through this quite carefully.
>
>
> ___
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

2018-01-04 Thread Joel Wirāmu Pauling 
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, dpr...@deepplum.com  wrote:

> I don't disagree that anyone who can run code in the hypervisor itself can
> 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", which
> 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āmu Pauling" 
> Sent: Thursday, January 4, 2018 5:00pm
> To: "dpr...@deepplum.com" 
> Cc: "Jonathan Morton" , cerowrt-devel@lists.
> bufferbloat.net
> Subject: Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches
> 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, dpr...@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
>> and 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
>> 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āmu 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
>>>
>>> ​Disagree - The Router is pretty much synonymous with NFV​
>>
>> ​; I run my lede instances at home on hypervisors - and this is
>> definitely the norm in Datacentres now. We need to work through this quite
>> carefully. ​
>>
>
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

2018-01-04 Thread dpr...@deepplum.com 

I don't disagree about using containers being useful as one of many security 
mechanisms. They are useful against certain attack vectors, but depend on two 
things: 1) kernel correctness, and 2) putting all functionality in separate 
userspace processes to satisfy the "principle of least privilege".
 
-Original Message-
From: "Dave Taht" 
Sent: Thursday, January 4, 2018 5:04pm
To: "dpr...@deepplum.com" 
Cc: "Joel Wirāmu Pauling" , "Jonathan Morton" 
, 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  wrote:
> 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.

Just to be clear, I was merely agreeing with joel that containers had
matured enough to be potentially usuable for some level of process
isolation and firewalling, not that it applied to coping with MeltRe.
>
>
>
> -Original Message-
> From: "Joel Wirāmu Pauling" 
> Sent: Thursday, January 4, 2018 4:52pm
> To: "Dave Taht" 
> Cc: "Jonathan Morton" ,
> cerowrt-devel@lists.bufferbloat.net
> Subject: Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches
> than x86?
>
> 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āmu 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
>> > definitely
>> > 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äht
>> CEO, TekLibre, LLC
>> http://www.teklibre.com
>> Tel: 1-669-226-2619



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

2018-01-04 Thread dpr...@deepplum.com 

I don't disagree that anyone who can run code in the hypervisor itself can 
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", which 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āmu Pauling" 
Sent: Thursday, January 4, 2018 5:00pm
To: "dpr...@deepplum.com" 
Cc: "Jonathan Morton" , 
cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches 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, [ dpr...@deepplum.com ]( mailto:dpr...@deepplum.com 
) <[ dpr...@deepplum.com ]( mailto:dpr...@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 and 
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 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āmu Pauling" <[ j...@aenertia.net ]( mailto:j...@aenertia.net )>
Sent: Thursday, January 4, 2018 4:44pm
To: "Jonathan Morton" <[ chromati...@gmail.com ]( mailto:chromati...@gmail.com 
)>
Cc: [ cerowrt-devel@lists.bufferbloat.net ]( 
mailto: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 <[ chromati...@gmail.com ]( 
mailto:chromati...@gmail.com )> 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 definitely the 
norm in Datacentres now. We need to work through this quite carefully. ​___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

2018-01-04 Thread Dave Taht 
On Thu, Jan 4, 2018 at 2:02 PM, dpr...@deepplum.com  wrote:
> 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.

Just to be clear, I was merely agreeing with joel that containers had
matured enough to be potentially usuable for some level of process
isolation and firewalling, not that it applied to coping with MeltRe.
>
>
>
> -Original Message-
> From: "Joel Wirāmu Pauling" 
> Sent: Thursday, January 4, 2018 4:52pm
> To: "Dave Taht" 
> Cc: "Jonathan Morton" ,
> cerowrt-devel@lists.bufferbloat.net
> Subject: Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches
> than x86?
>
> 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āmu 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
>> > definitely
>> > 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äht
>> CEO, TekLibre, LLC
>> http://www.teklibre.com
>> Tel: 1-669-226-2619



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

2018-01-04 Thread dpr...@deepplum.com 

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.
 
-Original Message-
From: "Joel Wirāmu Pauling" 
Sent: Thursday, January 4, 2018 4:52pm
To: "Dave Taht" 
Cc: "Jonathan Morton" , 
cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than 
x86?




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 <[ dave.t...@gmail.com ]( 
mailto:dave.t...@gmail.com )> wrote:


On Thu, Jan 4, 2018 at 1:44 PM, Joel Wirāmu Pauling <[ j...@aenertia.net ]( 
mailto:j...@aenertia.net )> wrote:
 >
 >
 > On 5 January 2018 at 01:09, Jonathan Morton <[ chromati...@gmail.com ]( 
 > mailto:chromati...@gmail.com )> 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 definitely
 > 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äht
 CEO, TekLibre, LLC
[ http://www.teklibre.com ]( http://www.teklibre.com )
 Tel: 1-669-226-2619___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

2018-01-04 Thread dpr...@deepplum.com 

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 and 
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 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āmu 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 <[ chromati...@gmail.com ]( 
mailto:chromati...@gmail.com )> 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 definitely the 
norm in Datacentres now. We need to work through this quite carefully. ​___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

2018-01-04 Thread Joel Wirāmu Pauling 
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, dpr...@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 and
> 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 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āmu 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
>>
>> ​Disagree - The Router is pretty much synonymous with NFV​
>
> ​; I run my lede instances at home on hypervisors - and this is definitely
> the norm in Datacentres now. We need to work through this quite carefully. ​
>
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

2018-01-04 Thread Joel Wirāmu Pauling 
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, Dave Taht  wrote:

> 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 to finally consider that
> feasible.
>
> >
> > 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.
>
> OK, so currently shipped gear is a big unknown then.
>
> >
> > On 5 January 2018 at 10:47, Dave Taht  wrote:
> >>
> >> On Thu, Jan 4, 2018 at 1:44 PM, Joel Wirāmu 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
> >> > definitely
> >> > 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äht
> >> CEO, TekLibre, LLC
> >> http://www.teklibre.com
> >> Tel: 1-669-226-2619
> >
> >
>
>
>
> --
>
> Dave Täht
> CEO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-669-226-2619
>
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

2018-01-04 Thread Dave Taht 
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 to finally consider that feasible.

>
> 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.

OK, so currently shipped gear is a big unknown then.

>
> On 5 January 2018 at 10:47, Dave Taht  wrote:
>>
>> On Thu, Jan 4, 2018 at 1:44 PM, Joel Wirāmu 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
>> > definitely
>> > 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äht
>> CEO, TekLibre, LLC
>> http://www.teklibre.com
>> Tel: 1-669-226-2619
>
>



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

2018-01-04 Thread valdis . kletnieks 
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 is allegedly shipping a
microcode fix for something believed to not be fixable via microcode. It
may be this is  a fix for only this one variant of the attack, and the other
two require kernel hacks.

Summary:

An update for microcode_ctl is now available for Red Hat Enterprise Linux 7.

Red Hat Product Security has rated this update as having a security impact of
Important. A Common Vulnerability Scoring System (CVSS) base score, which gives
a detailed severity rating, is available for each vulnerability from the CVE
link(s) in the References section.

The microcode_ctl packages provide microcode updates for Intel and AMD 
processors.

Security Fix(es):

* An industry-wide issue was found in the way many modern microprocessor
designs have implemented speculative execution of instructions (a commonly used
performance optimization). There are three primary variants of the issue which
differ in the way the speculative execution can be exploited. Variant
CVE-2017-5715 triggers the speculative execution by utilizing branch target It
relies on the presence of a precisely-defined instruction sequence in the
privileged code as well as the fact that memory accesses may cause allocation
into the microprocessor's data cache even for speculatively executed
instructions that never actually commit (retire). As a result, an unprivileged
attacker could use this flaw to cross the syscall and guest/host boundaries and
read privileged memory by conducting targeted cache side-channel attacks.
(CVE-2017-5715)

Note: This is the microcode counterpart of the CVE-2017-5715 kernel mitigation.
injection.


pgpxS6uvz9tTK.pgp
Description: PGP signature
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

2018-01-04 Thread Dave Taht 
On Thu, Jan 4, 2018 at 12:28 PM, dpr...@deepplum.com
 wrote:
> Depending on how you set up your "home router", you might allow "infected"
> or "trojan" programs to run in userspace there. I wouldn't do that, because
> hardware is cheap. But some people like to throw all kinds of server code
> into their router setups - even stuff like node.js servers.

I do not know if lua-jit is used in lede or openwrt these days, but
since so far as I recall the web server runs as root anyway, once you
have any control of that you are nearly home free in the first place.

>
>
>
> The really core issue with Meltdown at the highest level is that the kernel
> is addressable from userspace, except for the "privilege level" in the page
> table entries. That's a couple of bits between userspace and data that
> userspace isn't supposed to ever see. And those bits are ignored during
> specutlative execution's memory accesses.

It is really bad news for cloudy multi-tenant devices, but to a huge
extent that market can more rapidly adapt than anywhere else.

A fear is that millions of formerly high end and insecure chips are in
the pipeline and that they will get dumped into any market that will
take them, which certainly includes IoT. It's hard to imagine
shipments of any of 'em actually stopping for any reason, or being
dumped in the ocean on entrance to the country, like some form of
TwEAk party.

And despite the patches ongoing, it's not clear to me if the door can
ever be completely shut on this past generation of hardware still
deployed, I'm still looking over the interrupt related portions and
scratching my head. Significantly limit, yes, close, no.

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.

>
>
>
> -Original Message-
> From: "Dave Taht" 
> Sent: Thursday, January 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:
>>>
>>> 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 affected. These are all in-order
>> execution CPUs with short pipelines, and I think they're representative of
>> what you'd want in CPE.
>
> Well, I'd hope that this string of bugs stalls deployment of more
> advanced arches in this space until the speculative execution bugs are
> fully resolved.
>
> (and I *vastly* prefer short pipelines)
>
>> - Jonathan Morton
>>
>
>
>
> --
>
> Dave Täht
> CEO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-669-226-2619
> ___
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

2018-01-04 Thread Dave Taht 
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, Cortex-A7 and Cortex-A53 cores used by various 
> iterations of the Raspberry Pi are not affected.  These are all in-order 
> execution CPUs with short pipelines, and I think they're representative of 
> what you'd want in CPE.

Well, I'd hope that this string of bugs stalls deployment of more
advanced arches in this space until the speculative execution bugs are
fully resolved.

(and I *vastly* prefer short pipelines)

>  - Jonathan Morton
>



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

2018-01-04 Thread Jonathan Morton 
> 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 affected.  These are all in-order 
execution CPUs with short pipelines, and I think they're representative of what 
you'd want in CPE.

 - Jonathan Morton

___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

2018-01-04 Thread Dave Taht 
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  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 hardware just to meet existing loads.
>
> I think *AMD's* stock is going to go up a lot more than Intel's, because they 
> have pretty good server/workstation hardware now, and no vulnerability to the 
> most serious variants of this attack (which means no performance impact from 
> mitigation).  Apparently there are also mitigations for Spectre v1 and v2 
> which have minimal performance impact; Meltdown is the one which has a big 
> performance cost to deal with.
>
> Probably some ARM and PowerPC server vendors could get a boost too, but only 
> after their exposure to these attacks has been properly assessed.
>
>  - Jonathan Morton
>



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

2018-01-04 Thread Jonathan Morton 


> 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 hardware just to meet existing loads.

I think *AMD's* stock is going to go up a lot more than Intel's, because they 
have pretty good server/workstation hardware now, and no vulnerability to the 
most serious variants of this attack (which means no performance impact from 
mitigation).  Apparently there are also mitigations for Spectre v1 and v2 which 
have minimal performance impact; Meltdown is the one which has a big 
performance cost to deal with.

Probably some ARM and PowerPC server vendors could get a boost too, but only 
after their exposure to these attacks has been properly assessed.

 - Jonathan Morton

___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

2018-01-04 Thread Dave Taht 
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:
>
> https://www.reddit.com/r/Amd/comments/7o2i91/technical_analysis_of_spectre_meltdown/

On top of that, potential attacks are cpu-intensive as hell, at least
in their early stages.

I can't help but reflect on my favorite (sadly, still slidewire)
alternate cpu's characteristics, the mill.

It's a single address space in the first place, protection of memory
is to the byte, not the page (and done in a separate unit than the
TLB).
There are no syscalls, per se', instead an explicit capability gaining
(or dropping) portal call almost exactly like a subroutine.
the stack is protected from ROP. Stack and Registers have no rubble
(there are no registers, as we know them, either) that can be peered
at on call or return. Speculative execution is an intrinsic, well
documented part of the exposed processor pipeline: an explicit value
(NAR = not a result) is dropped anywhere there is the equivalent of
speculative execution. There isn't a conventional BTB, either (branch
exits are predicted via an undefined mechanism). In short, I think the
mill, as the closest thing to a pure capabilities arch that exists
today, would have (at least on paper) been invulnerable to this string
of attacks.

But the only way we'll ever find out is to build it. I keep calling
for more open processor designs (the risc-v is gaining some traction).
We really need more diversity in the infrastructure. I started
reminiscing fondly of the days when I used to use an old DEC alpha as
a firewall merely because I had more confidence it would be hard to
exploit than anything else.

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 hardware just to meet existing loads. Maybe power8 will regain
some traction. Cloud costs will jump, also, to compensate. (and it's
not just the cloud, anybody using a JIT on a desktop looks to be in
trouble - that includes java). And then, of course, would be a flood
of exploits over the next several years, attacking everything that
hasn't been patched.

And I'm hating the benchmarks thus far like that, because, latencies
are going to jump once again on servicing interrupts, and
that breaks a lot of assumptions in (for example) the virtualized
networking space, and context switches were already orders of
magnitude too slow for my taste and favorite applications (like
ardour.org).

> The TL;DR version is:
>
> - Spectre v1 affects pretty much any modern out-of-order CPU, but is 
> relatively low impact.  It could potentially be exploited using JIT 
> compilation of untrusted eBPF or Javascript, but can only exfiltrate data 
> from the local process.
>
> - Spectre v2 affects most recent Intel CPUs and some recent, high-performance 
> ARM CPU cores, but not AMD to any significant degree.  On vulnerable CPUs, it 
> allows a local attacker to exfiltrate data from privileged address space.
>
> - Meltdown is the nasty one which Linux kernel devs have been scrambling to 
> mitigate.  So far, it is known to affect only Intel x86 CPUs, due to their 
> unusually aggressive speculative behaviour regarding L1 cache hits.  On 
> vulnerable CPUs, it allows a local attacker to exfiltrate data from 
> privileged address space.
>
> I don't think we need to worry about it too much in a router context.  
> Virtual server folks, OTOH...
>
>  - Jonathan Morton
>



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

2018-01-04 Thread Jonathan Morton 
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:

- Spectre v1 affects pretty much any modern out-of-order CPU, but is relatively 
low impact.  It could potentially be exploited using JIT compilation of 
untrusted eBPF or Javascript, but can only exfiltrate data from the local 
process.

- Spectre v2 affects most recent Intel CPUs and some recent, high-performance 
ARM CPU cores, but not AMD to any significant degree.  On vulnerable CPUs, it 
allows a local attacker to exfiltrate data from privileged address space.

- Meltdown is the nasty one which Linux kernel devs have been scrambling to 
mitigate.  So far, it is known to affect only Intel x86 CPUs, due to their 
unusually aggressive speculative behaviour regarding L1 cache hits.  On 
vulnerable CPUs, it allows a local attacker to exfiltrate data from privileged 
address space.

I don't think we need to worry about it too much in a router context.  Virtual 
server folks, OTOH...

 - Jonathan Morton

___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel