Zombieload

[KBD]

intel problems continue
https://www.zdnet.com/article/linux-vs-zombieload/

[Artim]

Why are security fixes always a trade-off between security and performance? And why do software devs have to add all kindsa code to fix bad hardware? Rawr!

This almost makes me glad for my hardware that is older than 2011.

[KBD]

Why are security fixes always a trade-off between security and performance? And why do software devs have to add all kindsa code to fix bad hardware? Rawr!

This almost makes me glad for my hardware that is older than 2011.

It covers the full swath of most of my computers. I figure with every update/patch they diminish our computers. Of course intel would love for us to just buy new computers with their chips in them, but they are not inspiring confidence in their product :(

[Head_on_a_Stick]

Why are security fixes always a trade-off between security and performance? And why do software devs have to add all kindsa code to fix bad hardware?

Because Intel are a bunch of incompetent morons.

[KBD]

Interestingly, Google just disabled hyperthreading to help mitigate this on Chromebooks:
https://www.aboutchromebooks.com/news/c ... -security/

[Stevo]

Debian just pushed a new intel-microcode into Stretch security to mitigate the four new ones:

- CVE-2018-12126 [microarchitectural store buffer data sampling (MSBDS)] aka 'Fallout'
- CVE-2018-12130 [microarchitectural fill buffer data sampling (MFBDS)] aka 'ZombieLoad'
- CVE-2018-12127 [microarchitectural load port data sampling (MLPDS)] aka 'RIDL'
- CVE-2019-11091 [microarchitectural data sampling uncacheable memory (MDSUM)] aka 'RIDL'

I didn't see it pushed to Jessie, so we will have in the main MX 15/16 repo.

The new spectre-meltdown-checker 0.41 I just packaged and sent up scans for these and reported my system OK after rebooting with the new microcode. https://drive.google.com/open?id=1hwSIe ... McYR2FO6gU

[KBD]

Thanks for the info Stevo!

[Brigs]

Because Intel are a bunch of incompetent morons.

+1

Debian just pushed a new intel-microcode into Stretch security to mitigate the four new ones:

- CVE-2018-12126 [microarchitectural store buffer data sampling (MSBDS)] aka 'Fallout'
- CVE-2018-12130 [microarchitectural fill buffer data sampling (MFBDS)] aka 'ZombieLoad'
- CVE-2018-12127 [microarchitectural load port data sampling (MLPDS)] aka 'RIDL'
- CVE-2019-11091 [microarchitectural data sampling uncacheable memory (MDSUM)] aka 'RIDL'

I didn't see it pushed to Jessie, so we will have in the main MX 15/16 repo.

The new spectre-meltdown-checker 0.41 I just packaged and sent up scans for these and reported my system OK after rebooting with the new microcode. https://drive.google.com/open?id=1hwSIe ... McYR2FO6gU

Code: Select all

CVE-2018-12126 aka 'Fallout, microarchitectural store buffer data sampling (MSBDS)'
* CPU supports the MD_CLEAR functionality:  YES 
* Kernel supports using MD_CLEAR mitigation:  NO 
> STATUS:  VULNERABLE  (Your microcode supports mitigation, but your kernel doesn't, upgrade it to mitigate the vulnerability)

CVE-2018-12130 aka 'ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)'
* CPU supports the MD_CLEAR functionality:  YES 
* Kernel supports using MD_CLEAR mitigation:  NO 
> STATUS:  VULNERABLE  (Your microcode supports mitigation, but your kernel doesn't, upgrade it to mitigate the vulnerability)

CVE-2018-12127 aka 'RIDL, microarchitectural load port data sampling (MLPDS)'
* CPU supports the MD_CLEAR functionality:  YES 
* Kernel supports using MD_CLEAR mitigation:  NO 
> STATUS:  VULNERABLE  (Your microcode supports mitigation, but your kernel doesn't, upgrade it to mitigate the vulnerability)

CVE-2019-11091 aka 'RIDL, microarchitectural data sampling uncacheable memory (MDSUM)'
* CPU supports the MD_CLEAR functionality:  YES 
* Kernel supports using MD_CLEAR mitigation:  NO 
> STATUS:  VULNERABLE  (Your microcode supports mitigation, but your kernel doesn't, upgrade it to mitigate the vulnerability)

which kernel suggesting for mitigate those issue ?

[JayM]

This almost makes me glad for my hardware that is older than 2011.

Likewise. I plan to continue buying used or surplus computers rather than brand-new ones, should I buy another, and look for AMD CPUs in them. Not only are old surplus machines less expensive, buying those is also the green thing to do, reusing them instead of throwing them in a landfill, plus any issues with their CPUs and firmware has been fixed for a long time already. I don't play games as I find them boring after an hour or so, so I have no need of the latest, greatest, fastest, bestest computer. Old is fine, just as long as it doesn't break down on me and stop working.

[Stevo]

The 5.0-16 Liquorix kernel I just sent up doesn't show any vulnerabilities. I'm also rebuilding a new 4.19.0-5 4.19.37-2 kernel that Sid added yesterday with mitigations for those possible exploits.. It should be the default kernel in MX 18.3.

The latest Debian 4.9 kernel also has fixes for those.