Re: Spectre/meltdown fixes

On Fr, 2019-01-25 at 15:53 +0100, KP Kirchdoerfer via leaf-devel wrote:
> Hi Andrew;
> 
> On Do, 2019-01-24 at 17:41 +0200, Andrew wrote:
> > Hi all.
> > 
> > I upgraded one of BRASes to fresh LEAF 6.2 - and I saw that a lot
> > of
> > CPU 
> > time is wasted by spectre v2 protection:
> > 
> >     PerfTop:   12411 irqs/sec  kernel:97.7%  exact:  0.0% [4000Hz 
> > cycles],  (all, 4 CPUs)
> > -------------------------------------------------------------------
> > -------------------------------------------------------------------
> > ---------------------------------
> > 
> >       6.63%  [kernel]          [k] __indirect_thunk_start
> >       3.29%  [kernel]          [k] igb_alloc_rx_buffers
> >       2.82%  [kernel]          [k] memcpy
> >       2.69%  [kernel]          [k] ipt_do_table
> >       2.03%  [kernel]          [k] fib_table_lookup
> >       1.89%  [kernel]          [k] __netif_receive_skb_core
> >       1.66%  [kernel]          [k] htb_dequeue
> >       1.62%  [kernel]          [k] __skb_flow_dissect
> >       1.56%  [kernel]          [k] igb_xmit_frame_ring
> >       1.45%  bird              [.] 0x0000000000006a5c
> >       1.41%  [kernel]          [k] __dev_queue_xmit
> >       1.39%  [kernel]          [k] fib_table_flush
> >       1.29%  [kernel]          [k] leaf_walk_rcu
> >       1.25%  [kernel]          [k] irq_entries_start
> >       1.22%  [kernel]          [k] tcp_packet
> > 
> > Meltdown/spectre vulnerabilities are 1) exploitable mostly by 
> > local-running untrusted code, and 2) just can grant read access to
> > some 
> > protected memory pages (for ex., FS cache which can contain
> > passwords).
> > 
> > I think that this isn't a cases which are suitable for LEAF box
> > (which 
> > runs only trusted code, and which has no or almost no valuable
> > plaintext 
> > data).
> 
> You may be right, but better safe than sorry.
> 
> > I disabled it via kernel options, but maybe it'll be good to
> > disable 
> > these protections in kernel at build time?
> > 
> > Or as option, these protections may be disabled by default in
> > kernel 
> > command line, with mention in documentation about this.
> > 
> > Any thoughts?
> 
> Yes, I prefer The last one - "disabled by default on the kernel
> command
> line, but included in the kernel, and document how to enable
> protection
> by changing the kernel command line.
> 
> Eventually the other way round - document how to disable the
> protection
> and gain some more CPU time with disabling in kernel command line, as
> you did?
> 
> Either of these would be fine with me.
> What ever you choose, let me know what I should add to the wiki et
> el.

I've looked into again and we need to make a decision.

First: it's the Spectre_2 fix wasting CPU cycles, it can be disavbled
during boot with 
"spectre_v2=off" 
on the command line in syslinux.cfg.

Spectre_v2 (CVE-2017-5715: variant 2 - branch target injection) is
described as "Local attackers could use mis-predicted branches to
speculatively execute code patterns that in turn could be made to leak
otherwise non-readable content in the same address space,..."

Andrew made the point that we do not have "local attackers" so let's
turn it off by default and save CPU cycles/performance

On the other hand "local attackers" might not be users, but malicious
software delivered with an update of something we build but do not
fully understand the implications - I agree this is a very theoritical
example.

Anyway a decision has to be made:

Should the default be 
- be as secure as possible (probably without reason) and avoiding the
perfomance penalty is up to the user by changing the kernel commandline
in syslinux.cfg

versus

- disable Spectre V2 on the kernel commandline and it's up to the user
to decide wether he want's to change back to maximum theoretical
security even it has a performace issue.

Opinions are welcome.

kp