Re: [leaf-devel] Spectre/meltdown fixes

[Andrew <ni...@se...>]

I think that Spectre v1 may have same performance impact. About meltdown 
- I'm not sure (AFAIR it's solved by strict dividing kernel-space memory 
address space and userspace memory address space, which slows down 
kernel->userspace communications). I just discovered it on AMD hardware 
w/o Meltdown/Spectre v1 vulnerabilities.

On 12.02.2019 18:41, KP Kirchdoerfer via leaf-devel wrote:
> 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
>
>
>
>
>
> _______________________________________________
> leaf-devel mailing list
> lea...@li...
> https://lists.sourceforge.net/lists/listinfo/leaf-devel