From: Andrew <ni...@se...> - 2019-01-24 16:15:11
|
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). 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? |
From: KP K. <ka...@us...> - 2019-01-25 15:12:54
|
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. kp > > > > _______________________________________________ > leaf-devel mailing list > lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-devel |
From: KP K. <ka...@us...> - 2019-02-12 16:41:55
|
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 |
From: Andrew <ni...@se...> - 2019-02-12 17:12:29
|
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 |