Re: [Cerowrt-devel] Spectre and EBPF JIT

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] Spectre and EBPF JIT

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

[Cerowrt-devel] bufferbloat.net prep

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

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?

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

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

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

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

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

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

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

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

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

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,

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

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

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

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?

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

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