Meltdown and spectre

Chat
6

No: problems come from hardware design, you can’t fix hardware with software.
The updates mitigate the problems. Some workloads will suffer from reduced performances.
The impact is still being evaluated.

2 Likes
7

One of the most debated point is the impact that these workarounds will have into virtualization environment.
It’s almost the fourth “big crack” for hardware or software found during last 6 months. Only WannaCry spotted a patch out-of-release schedule.
I’m quite concerned.

8

some more info on performance impacts:

it’s nice the first solution on the page of the cert :grin: :sob:

meltdownspectre.png705×190 7.99 KB

9

Is not required to replace your current CPU by tomorrow… yet… (unless tomorrow will be 6 months from now and you still did not patch your systems)

Depending on the “weight” of the patch you can still manage to do with current infra load. (you did over-provision your resource load I hope… :wink: )

Of course the replacement of the HW will be the solution in the long run (an alternative is not yet available).

in my opinion, this issue does not pose an immediate (read as today/tomorrow) risk since this vulnerability is not easy exploitable. And also keep in mind that there are other factors that keep the exploit in check. (Policies, certified/trusted software, AV etc)

First, a malicious program, will have to get over the usual barriers and then, will be able to deliver the payload to do the seep on the memory pages… (except web content :wink: )

We will see POC and first attempts in the next days but also the patches will arrive, so mostly it will be a game of “who is good at housekeeping” and maintenance.

The most impacted will probably be the hosts like esx and xen etc.
They will need to patch asap because you might not have control on what is run on your guest, if the guest is public service.

And on the fun side, the mass-media started to have a incendiary start reporting this :slight_smile: With lots of headlines (90% related only to Intel :smiley: )

4 Likes
10

Some more background:
Meltdown vs Spectre: https://danielmiessler.com/blog/simple-explanation-difference-meltdown-spectre/

Linux kernel patches for Meltdown: https://lkml.org/lkml/2017/12/4/709 (patches for kernel 4.15 are available with backports for 4.14.10. (that would be a problem for NS right?)
Microsoft patch for W10: https://support.microsoft.com/en-us/help/4073119/windows-client-guidance-for-it-pros-to-protect-against-speculative-exe
MacOS is patched from version 10.13.2 (according to The Register.

Interesting blogpost from Google’s ProjectZero: https://googleprojectzero.blogspot.be/

I am not that deeply involved in kernel updates, but if there will be an update for the latest kernel version, would it be a good/bad (why) idea to add the elrepo repository to be able to update CentOS/NethServer to a patched kernel version? See https://www.tecmint.com/install-upgrade-kernel-version-in-centos-7/

11

Some benchmarks by Red Hat:
https://www.reddit.com/r/sysadmin/comments/7nyhc5/meltdown_and_spectre/ds5m76i/
Phoronix has been running some other tests with Redis, Postgresql…

Related to this thread:

12

I started patching my ESXis, if someone needs patched images:

https://www.markusneuberger.at/category/software/

Nothing needed, it’s already in upstream:

13

Today my NS6 received the kernel 2.6.32-696.18.7.el6 with is the patched one according to
http://www.linuxsecurity.com/content/view/206190?rdf
https://access.redhat.com/errata/RHSA-2018:0008

It’s not installed until now. I want to explore the so hot discused impact on the system.
I noted down the avg. load values for 2h, 8h, day, week and month. So I can compare them later.
Can some one give me some instructions how to compare the impact directly?

TIA

1 Like
14

BTW, remarkable news: https://arstechnica.com/information-technology/2018/01/intel-ceos-sale-of-stock-just-before-security-bug-reveal-raises-questions/
The rats leave the sinking ship first?

15

As you know, information is the gold of today.
Or say it with Goethe: A rogue who thinks bad upon it. (german: Ein Schlem, wer böses dabei denkt.) :wink:

16

well, it seems that Nehtserver on raspberry pi is not affected… :slight_smile:
(and i suppose also my home firewall on odroid-c2)

if anyone is interested, i suggest this great and amazingly clear article of Eben Upton

4 Likes
17

Odroid-C2 has cortex-a53 cores, and thus is not affected…:yum:

3 Likes
18

Silly question : is it needed to restart the server to apply the patch ?

19

Any kernel updates requires the server to be restarted.

2 Likes
20

Thanks. It may sounds obvious, but I wish yum or whatever package manager mentions it.

21

Beware, apart of CentOS patches, some systems need a firmware update to mitigate the vulnerabilities, so remember to check if manufacturer has released patches… as @filippo_carletti pointed out.

22

some updates from centos:

#CentOS users need to look at: http://red.ht/2DHia30 @RedHatSoftware has removed the latest microcode.dat file from the latest RPMs. Users must get their own microcode from their hardware vendors. This is from Intel: http://intel.ly/2CJTVQr

from centos announce:
https://lists.centos.org/pipermail/centos-announce/2018-January/022709.html
https://lists.centos.org/pipermail/centos-announce/2018-January/022710.html
https://lists.centos.org/pipermail/centos-announce/2018-January/022711.html

and a nice howto:

3 Likes
23

Really interesting, thank you for sharing!

24

Do I understand correctly that RedHat is taking its hands off from vulnerable code and leaves it to the hardware vendors tos solve? Understandable from RedHat point of view, but it feels like sticking the neck in the sand and point to someone else…

I just ran the test on my OpenSuSE laptop (new install with latest updates):

linux-3r35:/tmp/spectre-meltdown-checker # sh spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.31

Checking for vulnerabilities against running kernel Linux 4.4.104-39-default #1 SMP Thu Jan 4 08:11:03 UTC 2018 (7db1912) x86_64
CPU is Intel(R) Core™ i5-4200M CPU @ 2.50GHz

CVE-2017-5753 [bounds check bypass] aka ‘Spectre Variant 1’

  • Checking count of LFENCE opcodes in kernel: YES

STATUS: NOT VULNERABLE (92 opcodes found, which is >= 70, heuristic to be improved when official patches become available)

CVE-2017-5715 [branch target injection] aka ‘Spectre Variant 2’

  • Mitigation 1
  • Hardware (CPU microcode) support for mitigation
  • The SPEC_CTRL MSR is available:  YES 

  • The SPEC_CTRL CPUID feature bit is set:  YES
  • Kernel support for IBRS: NO
  • IBRS enabled for Kernel space: NO
  • IBRS enabled for User space: NO
  • Mitigation 2
  • Kernel compiled with retpoline option: NO
  • Kernel compiled with a retpoline-aware compiler: NO

STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka ‘Meltdown’ aka ‘Variant 3’

  • Kernel supports Page Table Isolation (PTI): YES
  • PTI enabled and active: YES
  • Checking if we’re running under Xen PV (64 bits): NO
    STATUS: NOT VULNERABLE (PTI mitigates the vulnerability)

A false sense of security is worse than no security at all, see --disclaimer

2 Likes
25

It’s a hardware problem to be solved by hardware vendors.
Redhat (and others) is mitigating the issue.

1 Like