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 :(Artim wrote: Wed May 15, 2019 2:38 am 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.
Because Intel are a bunch of incompetent morons.Artim wrote: Wed May 15, 2019 2:38 am 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?
I didn't see it pushed to Jessie, so we will have in the main MX 15/16 repo.- 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'
+1
Stevo wrote: Wed May 15, 2019 7:15 pm Debian just pushed a new intel-microcode into Stretch security to mitigate the four new ones:
I didn't see it pushed to Jessie, so we will have in the main MX 15/16 repo.- 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'
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)
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.Artim wrote: Wed May 15, 2019 2:38 am This almost makes me glad for my hardware that is older than 2011.
If this keeps up, we are all going to have to buy or dig out single core CPU machines for online use when we are buying, banking, pretty much anything online. And those machines will be as fast as dual-core intel CPU's by the time we get to the end of all these migrations.JayM wrote: Wed May 15, 2019 8:53 pm 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.
True you're saving them from landfill but old computers use vastly greater amounts of electricity than new ones to do the same work.JayM wrote: Wed May 15, 2019 8:53 pmNot 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,...
They still need to tweak the spectre-meltdown-checker.Stevo wrote: Wed May 15, 2019 7:15 pm 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.
The upstream script was corrected 12 hours ago:timkb4cq wrote: Thu May 16, 2019 1:16 pm They still need to tweak the spectre-meltdown-checker.
It shows my AMD FX6300 system to be vulnerable to Zombieload, Fallout and the two RIDL vulnerablilities.
Code: Select all
grep -R . /sys/devices/system/cpu/vulnerabilities/
^ The MDS line refers to the new vulnerabilities.beardedragon wrote: Thu May 16, 2019 5:49 pmCode: Select all
/sys/devices/system/cpu/vulnerabilities/mds:Mitigation: Clear CPU buffers; SMT disabled
Some how I thought most of these problems went with AMD, not so?Head_on_a_Stick wrote: Thu May 16, 2019 6:08 pm To clarify:^ The MDS line refers to the new vulnerabilities.beardedragon wrote: Thu May 16, 2019 5:49 pmCode: Select all
/sys/devices/system/cpu/vulnerabilities/mds:Mitigation: Clear CPU buffers; SMT disabled
Code: Select all
$ inxi -Fxzc0
System: Host: MX Kernel: 5.0.0-16.1-liquorix-amd64 x86_64 bits: 64 compiler: gcc v: 6.3.0
Desktop: Xfce 4.12.3 Distro: MX-18.2_x64 Continuum Apr 7 2019
base: Debian GNU/Linux 9 (stretch)
Machine: Type: Desktop System: LENOVO product: 10181 v: Lenovo K450e serial: <filter>
Mobo: LENOVO model: N/A v: 31900058 STD serial: <filter> BIOS: LENOVO v: I1KT38AUS
date: 06/10/2014
Battery: Device-1: hidpp_battery_0 model: Logitech M570 charge: 90% status: Discharging
CPU: Topology: Quad Core model: Intel Core i5-4460 bits: 64 type: MCP arch: Haswell rev: 3
L2 cache: 6144 KiB
flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 25540
Speed: 798 MHz min/max: 800/3400 MHz Core speeds (MHz): 1: 798 2: 798 3: 798 4: 798
Graphics: Device-1: NVIDIA GK208 [GeForce GT 720] vendor: Micro-Star MSI driver: nvidia
v: 430.14 bus ID: 01:00.0
Display: x11 server: X.Org 1.19.2 driver: nvidia resolution: 1920x1080~60Hz
OpenGL: renderer: GeForce GT 720/PCIe/SSE2 v: 4.6.0 NVIDIA 430.14 direct render: Yes
Audio: Device-1: Intel 8 Series/C220 Series High Definition Audio vendor: Lenovo
driver: snd_hda_intel v: kernel bus ID: 00:1b.0
Device-2: NVIDIA GK208 HDMI/DP Audio vendor: Micro-Star MSI driver: snd_hda_intel
v: kernel bus ID: 01:00.1
Sound Server: ALSA v: k5.0.0-16.1-liquorix-amd64
Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: Lenovo
driver: r8169 v: kernel port: d000 bus ID: 03:00.0
IF: eth0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Drives: Local Storage: total: 1.82 TiB used: 26.61 GiB (1.4%)
ID-1: /dev/sda vendor: Western Digital model: WD10EZEX-08M2NA0 size: 931.51 GiB
ID-2: /dev/sdd type: USB vendor: Western Digital model: WD Elements 25A2
size: 931.48 GiB
Partition: ID-1: / size: 913.89 GiB used: 26.61 GiB (2.9%) fs: ext4 dev: /dev/sda1
ID-2: swap-1 size: 2.00 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sda2
Sensors: System Temperatures: cpu: 44.0 C mobo: N/A gpu: nvidia temp: 51 C
Fan Speeds (RPM): N/A gpu: nvidia fan: 28%
Info: Processes: 236 Uptime: 2h 19m Memory: 7.72 GiB used: 780.7 MiB (9.9%) Init: SysVinit
runlevel: 5 Compilers: gcc: 6.3.0 Shell: bash v: 4.4.12 inxi: 3.0.33
The older kernels don't know anything about the new possible exploits, so can't report that they are mitigated.beardedragon wrote: Thu May 16, 2019 5:49 pm Bump:
bob@MX:~
$ grep -R . /sys/devices/system/cpu/vulnerabilities/
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: disabled, RSB filling
/sys/devices/system/cpu/vulnerabilities/mds:Mitigation: Clear CPU buffers; SMT disabled
/sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
So your kernel version is critical.Gives a 404 error. URL not found. It is a truncated url.I have new packages of the checker, though: https://drive.google.com/open?id=1LWm3S ... JxftAR--YK_
Yes a 404 not found. What should I do? Reinstall and not use that kernel?Stevo wrote: Thu May 16, 2019 6:34 pm
The older kernels don't know anything about the new possible exploits, so can't report that they are mitigated.
I have new packages of the checker, though: https://drive.google.com/open?id=1LWm3S ... JxftAR--YK_
those two are for mx 16 and mx 17.
The MX 17 version will work on mX 18.2beardedragon wrote: Thu May 16, 2019 6:55 pmthose two are for mx 16 and mx 17.
I have mx 18.2 Updated?
Code: Select all
bob@MX:~
$ sudo sh spectre-meltdown-checker.sh --explain
Spectre and Meltdown mitigation detection tool v0.41
Checking for vulnerabilities on current system
Kernel is Linux 5.0.0-16.1-liquorix-amd64 #1 ZEN SMP PREEMPT liquorix 5.0-16~mx17+1 (2019-05-15) x86_64
CPU is Intel(R) Core(TM) i5-4460 CPU @ 3.20GHz
Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: YES
* CPU indicates IBRS capability: YES (SPEC_CTRL feature bit)
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: YES
* CPU indicates IBPB capability: YES (SPEC_CTRL feature bit)
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: YES
* CPU indicates STIBP capability: YES (Intel STIBP feature bit)
* Speculative Store Bypass Disable (SSBD)
* CPU indicates SSBD capability: YES (Intel SSBD)
* L1 data cache invalidation
* FLUSH_CMD MSR is available: YES
* CPU indicates L1D flush capability: YES (L1D flush feature bit)
* Microarchitecture Data Sampling
* VERW instruction is available: YES (MD_CLEAR feature bit)
* Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability: NO
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
* CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO
* CPU explicitly indicates not being vulnerable to Variant 4 (SSB_NO): NO
* CPU/Hypervisor indicates L1D flushing is not necessary on this system: NO
* Hypervisor indicates host CPU might be vulnerable to RSB underflow (RSBA): NO
* CPU explicitly indicates not being vulnerable to Microarchitectural Data Sampling (MDC_NO): NO
* CPU supports Software Guard Extensions (SGX): NO
* CPU microcode is known to cause stability problems: NO (model 0x3c family 0x6 stepping 0x3 ucode 0x27 cpuid 0x306c3)
* CPU microcode is the latest known available version: YES (latest version is 0x27 dated 2019/02/26 according to builtin MCExtractor DB v110 - 2019/05/11)
* CPU vulnerability to the speculative execution attack variants
* Vulnerable to CVE-2017-5753 (Spectre Variant 1, bounds check bypass): YES
* Vulnerable to CVE-2017-5715 (Spectre Variant 2, branch target injection): YES
* Vulnerable to CVE-2017-5754 (Variant 3, Meltdown, rogue data cache load): YES
* Vulnerable to CVE-2018-3640 (Variant 3a, rogue system register read): YES
* Vulnerable to CVE-2018-3639 (Variant 4, speculative store bypass): YES
* Vulnerable to CVE-2018-3615 (Foreshadow (SGX), L1 terminal fault): NO
* Vulnerable to CVE-2018-3620 (Foreshadow-NG (OS), L1 terminal fault): YES
* Vulnerable to CVE-2018-3646 (Foreshadow-NG (VMM), L1 terminal fault): YES
* Vulnerable to CVE-2018-12126 (Fallout, microarchitectural store buffer data sampling (MSBDS)): YES
* Vulnerable to CVE-2018-12130 (ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)): YES
* Vulnerable to CVE-2018-12127 (RIDL, microarchitectural load port data sampling (MLPDS)): YES
* Vulnerable to CVE-2019-11091 (RIDL, microarchitectural data sampling uncacheable memory (MDSUM)): YES
CVE-2017-5753 aka 'Spectre Variant 1, bounds check bypass'
* Mitigated according to the /sys interface: YES (Mitigation: __user pointer sanitization)
* Kernel has array_index_mask_nospec: UNKNOWN (couldn't check (missing 'lzop' tool, please install it, usually it's in the 'lzop' package))
* Kernel has the Red Hat/Ubuntu patch: UNKNOWN (couldn't check (missing 'lzop' tool, please install it, usually it's in the 'lzop' package))
* Kernel has mask_nospec64 (arm64): UNKNOWN (couldn't check (missing 'lzop' tool, please install it, usually it's in the 'lzop' package))
* Checking count of LFENCE instructions following a jump in kernel... UNKNOWN (couldn't check (missing 'lzop' tool, please install it, usually it's in the 'lzop' package))
> STATUS: NOT VULNERABLE (Mitigation: __user pointer sanitization)
CVE-2017-5715 aka 'Spectre Variant 2, branch target injection'
* Mitigated according to the /sys interface: YES (Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: disabled, RSB filling)
* Mitigation 1
* Kernel is compiled with IBRS support: YES
* IBRS enabled and active: YES (for firmware code only)
* Kernel is compiled with IBPB support: YES
* IBPB enabled and active: YES
* Mitigation 2
* Kernel has branch predictor hardening (arm): NO
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
> STATUS: NOT VULNERABLE (Full retpoline + IBPB are mitigating the vulnerability)
CVE-2017-5754 aka 'Variant 3, Meltdown, rogue data cache load'
* Mitigated according to the /sys interface: YES (Mitigation: PTI)
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
* Reduced performance impact of PTI: YES (CPU supports INVPCID, performance impact of PTI will be greatly reduced)
* Running as a Xen PV DomU: NO
> STATUS: NOT VULNERABLE (Mitigation: PTI)
CVE-2018-3640 aka 'Variant 3a, rogue system register read'
* CPU microcode mitigates the vulnerability: YES
> STATUS: NOT VULNERABLE (your CPU microcode mitigates the vulnerability)
CVE-2018-3639 aka 'Variant 4, speculative store bypass'
* Mitigated according to the /sys interface: YES (Mitigation: Speculative Store Bypass disabled via prctl and seccomp)
* Kernel supports disabling speculative store bypass (SSB): YES (found in /proc/self/status)
* SSB mitigation is enabled and active: YES (per-thread through prctl)
* SSB mitigation currently active for selected processes: YES (chrome)
> STATUS: NOT VULNERABLE (Mitigation: Speculative Store Bypass disabled via prctl and seccomp)
CVE-2018-3615 aka 'Foreshadow (SGX), L1 terminal fault'
* CPU microcode mitigates the vulnerability: N/A
> STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable)
CVE-2018-3620 aka 'Foreshadow-NG (OS), L1 terminal fault'
* Mitigated according to the /sys interface: YES (Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled)
* Kernel supports PTE inversion: strings: '': No such file
NO
* PTE inversion enabled and active: YES
> STATUS: NOT VULNERABLE (Mitigation: PTE Inversion)
CVE-2018-3646 aka 'Foreshadow-NG (VMM), L1 terminal fault'
* Information from the /sys interface: VMX: conditional cache flushes, SMT disabled
* This system is a host running a hypervisor: NO
* Mitigation 1 (KVM)
* EPT is disabled: NO
* Mitigation 2
* L1D flush is supported by kernel: YES (found flush_l1d in /proc/cpuinfo)
* L1D flush enabled: YES (conditional flushes)
* Hardware-backed L1D flush supported: YES (performance impact of the mitigation will be greatly reduced)
* Hyper-Threading (SMT) is enabled: NO
> STATUS: NOT VULNERABLE (this system is not running a hypervisor)
CVE-2018-12126 aka 'Fallout, microarchitectural store buffer data sampling (MSBDS)'
* Mitigated according to the /sys interface: YES (Mitigation: Clear CPU buffers; SMT disabled)
* CPU supports the MD_CLEAR functionality: YES
* Kernel supports using MD_CLEAR mitigation: YES (md_clear found in /proc/cpuinfo)
* Kernel mitigation is enabled and active: YES
* SMT is either mitigated or disabled: YES
> STATUS: NOT VULNERABLE (Mitigation: Clear CPU buffers; SMT disabled)
CVE-2018-12130 aka 'ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)'
* Mitigated according to the /sys interface: YES (Mitigation: Clear CPU buffers; SMT disabled)
* CPU supports the MD_CLEAR functionality: YES
* Kernel supports using MD_CLEAR mitigation: YES (md_clear found in /proc/cpuinfo)
* Kernel mitigation is enabled and active: YES
* SMT is either mitigated or disabled: YES
> STATUS: NOT VULNERABLE (Mitigation: Clear CPU buffers; SMT disabled)
CVE-2018-12127 aka 'RIDL, microarchitectural load port data sampling (MLPDS)'
* Mitigated according to the /sys interface: YES (Mitigation: Clear CPU buffers; SMT disabled)
* CPU supports the MD_CLEAR functionality: YES
* Kernel supports using MD_CLEAR mitigation: YES (md_clear found in /proc/cpuinfo)
* Kernel mitigation is enabled and active: YES
* SMT is either mitigated or disabled: YES
> STATUS: NOT VULNERABLE (Mitigation: Clear CPU buffers; SMT disabled)
CVE-2019-11091 aka 'RIDL, microarchitectural data sampling uncacheable memory (MDSUM)'
* Mitigated according to the /sys interface: YES (Mitigation: Clear CPU buffers; SMT disabled)
* CPU supports the MD_CLEAR functionality: YES
* Kernel supports using MD_CLEAR mitigation: YES (md_clear found in /proc/cpuinfo)
* Kernel mitigation is enabled and active: YES
* SMT is either mitigated or disabled: YES
> STATUS: NOT VULNERABLE (Mitigation: Clear CPU buffers; SMT disabled)
> SUMMARY: CVE-2017-5753:OK CVE-2017-5715:OK CVE-2017-5754:OK CVE-2018-3640:OK CVE-2018-3639:OK CVE-2018-3615:OK CVE-2018-3620:OK CVE-2018-3646:OK CVE-2018-12126:OK CVE-2018-12130:OK CVE-2018-12127:OK CVE-2019-11091:OK
A false sense of security is worse than no security at all, see --disclaimer
The output that you have quoted lists the new MDS vulnerability therefore the kernel knows about it and is reporting that it is mitigated.Stevo wrote: Thu May 16, 2019 6:34 pmThe older kernels don't know anything about the new possible exploits, so can't report that they are mitigated.beardedragon wrote: Thu May 16, 2019 5:49 pm Bump:
bob@MX:~
$ grep -R . /sys/devices/system/cpu/vulnerabilities/
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: disabled, RSB filling
/sys/devices/system/cpu/vulnerabilities/mds:Mitigation: Clear CPU buffers; SMT disabled
/sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
Actually the center portion is missing. The link I posted using verbiage with the full underlying link works fine.timkb4cq wrote: Thu May 16, 2019 7:26 pm The problem is that the last character of the link is an underscore ( _ ). Underscores at the end of a link don't show up as part of the link but are shown appended after. You can add it manually in the address bar and hit enter after the link fails.
Good news, yes?
same error. It is an odd thing that phpBB does, truncating long url's. To get around it use the method I postedStevo wrote: Thu May 16, 2019 7:39 pm OK, try this link: https://drive.google.com/open?id=1LWm3S ... JxftAR--YK_
Code: Select all
[url=the actual url]desired describing text]/urlYou already have it in the package I did for it. You will get the same results if you run
Code: Select all
sudo ./spectre-meltdown-checker.shCode: Select all
bob@MX:~/Downloads
$ sudo ./spectre-meltdown-checker.sh
sudo: ./spectre-meltdown-checker.sh: command not found
I may rethink my position then. It's like we say in the Pacific Northwest: every time you turn on the lights, a salmon dies. No matter what we do, we impact our environment somehow.sunrat wrote: Thu May 16, 2019 1:04 pmTrue you're saving them from landfill but old computers use vastly greater amounts of electricity than new ones to do the same work.JayM wrote: Wed May 15, 2019 8:53 pmNot 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,...
Says sunrat typing on his 11 year old Core2Duo system.
you could just wait. i mean there is noting worse to do than panicbeardedragon wrote: Thu May 16, 2019 8:30 pm I give up,I am going to install fresh and not use that kernel.
Too little too late, done.MadmanRB wrote: Thu May 16, 2019 10:13 pmyou could just wait. i mean there is noting worse to do than panicbeardedragon wrote: Thu May 16, 2019 8:30 pm I give up,I am going to install fresh and not use that kernel.
Make sure it is executable. Make sure you are in the same directory as the script.beardedragon wrote: Thu May 16, 2019 8:05 pmCode: Select all
bob@MX:~/Downloads $ sudo ./spectre-meltdown-checker.sh sudo: ./spectre-meltdown-checker.sh: command not found
I'm going to let it all hang out here saying that if you are on a single user or family computer that isn't performing any server functions exposed directly to the Internet (i.e. behind a router with NAT), and you haven't exposed ports to unauthenticated users, it's not very important. Users should evaluate their own exposure and consider reducing that exposure, eliminating exposure to the extent possible. Practicing safe computing is more important that locking down the CPU. Disclaimer -- this is my reasonably informed opinion.KBD wrote: Thu May 16, 2019 11:03 pm Question guys: How important is it to disable hyper-threading? Google is doing it now with ChromeOS. I wouldn't even know how to start to disable this, or if it even makes sense in Linux. What do you folks think about hyper-threading and avoiding some of these intel issues by disabling it?
just use: $ sudo spectre-meltdown-checkerbeardedragon wrote: Thu May 16, 2019 8:05 pmCode: Select all
bob@MX:~/Downloads $ sudo ./spectre-meltdown-checker.sh sudo: ./spectre-meltdown-checker.sh: command not found
I would recommend disabling SMT for Intel hardware, there are almost certainly many more undiscovered vulnerabilities that can take advantage of Intel's broken microarchitecture.
The kernel you were using was protected according to the /sys content you posted earlier.beardedragon wrote: Thu May 16, 2019 8:30 pm I give up,I am going to install fresh and not use that kernel.
Hey, it's just my opinion
Thanks for sharing you thoughts!figueroa wrote: Thu May 16, 2019 11:29 pm I'm going to let it all hang out here saying that if you are on a single user or family computer that isn't performing any server functions exposed directly to the Internet (i.e. behind a router with NAT), and you haven't exposed ports to unauthenticated users, it's not very important. Users should evaluate their own exposure and consider reducing that exposure, eliminating exposure to the extent possible. Practicing safe computing is more important that locking down the CPU. Disclaimer -- this is my reasonably informed opinion.
Well that's hardly surprising given that they were only made public a few days ago.figueroa wrote: Fri May 17, 2019 11:29 am Consider that there are no known in-the-wild exploits of these flaws
MX Kernel: 5.0.0-16.1-liquorix-amd64 x86_64 bits
Quoting from the article:Head_on_a_Stick wrote: Fri May 17, 2019 11:41 am Well that's hardly surprising given that they were only made public a few days ago.
... So the only and unique alternative, for almost everyone, is to trust in researchers who find ;-)figueroa wrote: Fri May 17, 2019 2:11 pmQuoting from the article:Head_on_a_Stick wrote: Fri May 17, 2019 11:41 am Well that's hardly surprising given that they were only made public a few days ago.
"Thus far, no attacks actually utilizing Spectre and Meltdown have been spotted in the wild, beyond proof-of-concept work submitted by researchers."
This reflects on ALL of the last 17 months' uncovered vulnerabilities.
That's not what I'm saying. Mitigate what you can, subject to your resources and your needs. Don't sell the farm. Don't panic. Reduce your exposure. Practice safe computing. Nobody has been successfully attacked this way, yet.oops wrote: Fri May 17, 2019 2:22 pm ... So the only and unique alternative, for almost everyone, is to trust in researchers who find ;-)
Why don't you either patch the kernels and upgrade them. or. drop them and advise the rest of the users to do so.figueroa wrote: Fri May 17, 2019 2:59 pmThat's not what I'm saying. Mitigate what you can, subject to your resources and your needs. Don't sell the farm. Don't panic. Reduce your exposure. Practice safe computing. Nobody has been successfully attacked this way, yet.oops wrote: Fri May 17, 2019 2:22 pm ... So the only and unique alternative, for almost everyone, is to trust in researchers who find ;-)
beardedragon wrote: Fri May 17, 2019 3:02 pmWhy don't you either patch the kernels and upgrade them. or. drop them and advise the rest of the users to do so?figueroa wrote: Fri May 17, 2019 2:59 pmThat's not what I'm saying. Mitigate what you can, subject to your resources and your needs. Don't sell the farm. Don't panic. Reduce your exposure. Practice safe computing. Nobody has been successfully attacked this way, yet.oops wrote: Fri May 17, 2019 2:22 pm ... So the only and unique alternative, for almost everyone, is to trust in researchers who find ;-)
Yes it's easy red is bad, green is good, and not already discovered will be reds next, the problem is; times after times, some new red items are discovered. (and the good news; it's for the moment always before a massive impact)Stevo wrote: Fri May 17, 2019 3:00 pm Green is good in the script output, red is bad. You need to ask questions how to fix it if you get red results and need help. Seems pretty easy to me!
Absence of evidence is not evidence of absence.figueroa wrote: Fri May 17, 2019 2:11 pm Quoting from the article:
"Thus far, no attacks actually utilizing Spectre and Meltdown have been spotted in the wild, beyond proof-of-concept work submitted by researchers."
I am sitting on Debian Testing, waiting for you guys to get this straightened out. At least it works without holes in the kernel.beardedragon wrote: Thu May 16, 2019 8:30 pm I give up, I am going to install fresh and not use that kernel.
The risk does not warrant such extreme actions. It could also be rhetorically stated why don't all users change to AMD CPUs?beardedragon wrote: Fri May 17, 2019 3:02 pm Why don't you either patch the kernels and upgrade them. or. drop them and advise the rest of the users to do so.
The kernels are already patched and in the repos. The 5.0-16 Liquorix kernel is also not vulnerable, as the checker output told you.beardedragon wrote: Fri May 17, 2019 3:02 pmWhy don't you either patch the kernels and upgrade them. or. drop them and advise the rest of the users to do so.figueroa wrote: Fri May 17, 2019 2:59 pmThat's not what I'm saying. Mitigate what you can, subject to your resources and your needs. Don't sell the farm. Don't panic. Reduce your exposure. Practice safe computing. Nobody has been successfully attacked this way, yet.oops wrote: Fri May 17, 2019 2:22 pm ... So the only and unique alternative, for almost everyone, is to trust in researchers who find ;-)
Mitigate: To make less severe, intense, harsh, rigorous, painful,Stevo wrote: Fri May 17, 2019 6:09 pmThe kernels are already patched and in the repos. The 5.0-16 Liquorix kernel is also not vulnerable, as the checker output told you.beardedragon wrote: Fri May 17, 2019 3:02 pmWhy don't you either patch the kernels and upgrade them. or. drop them and advise the rest of the users to do so.figueroa wrote: Fri May 17, 2019 2:59 pm
That's not what I'm saying. Mitigate what you can, subject to your resources and your needs. Don't sell the farm. Don't panic. Reduce your exposure. Practice safe computing. Nobody has been successfully attacked this way, yet.
Fixing the problem would Intel recalling and replacing all of its vulnerable CPUs at Intel's expense. Mitigating the problem is patching Linux kernels such that CPU-induced security vulnerabilities can't affect the operating system. It's not Linux's problem, yet they've patched their kernel to prevent Intel's microcode vulnerabilities from being able to be exploited in Linux. That's why it's called a mitigation, not a "fix" or a solution. It's more of a work-around. It effectively fixes the problem, but since the source of the problem is within Intel's microcode that's where an actual "fix" would need to be applied.beardedragon wrote: Fri May 17, 2019 8:36 pmMitigate: To make less severe, intense, harsh, rigorous, painful,Stevo wrote: Fri May 17, 2019 6:09 pmThe kernels are already patched and in the repos. The 5.0-16 Liquorix kernel is also not vulnerable, as the checker output told you.beardedragon wrote: Fri May 17, 2019 3:02 pm
Why don't you either patch the kernels and upgrade them. or. drop them and advise the rest of the users to do so.
etc.; to soften; to meliorate; to alleviate; to diminish;
to lessen; as, to mitigate heat or cold; to mitigate
grief.
[1913 Webster]
That does not look like fixing the problem. Why even bring this up, or, use a topic that the average user would not even read? Sorry, I am probably too cautious, but, the main reason I do not use Windows is they have too many mitigating circumstances and it is a hacker's dream. I quit using Manjaro after years testing and stable because the main designer took a vacation and everything went to pot, The white screen of death was the result of changing something in nvidia they had no reason to change when they upgraded two kernels. Sorry if I offended you.
Code: Select all
[Desktop Entry]
Version=1.0
# fehlix: 2019-05-18
# file: spectre-meltdown-checker.desktop
# Zombieload thread: https://forum.mxlinux.org/viewtopic.php?p=503075#p503075
#
Type=Application
Name=Spectre and Meltdown Checker
Comment=Spectre and Meltdown mitigation detection tool
Exec=x-terminal-emulator -T "Spectre and Meltdown Checker" -e bash -c '( hash spectre-meltdown-checker 2>/dev/null || sudo apt install spectre-meltdown-checker) && sudo spectre-meltdown-checker | tee >( (echo "[""code]"; cat ; echo "[/""code]" ) | sed "s/\x1b\[[0-9;]*[mGKH]//g" | xsel -ib 2> /dev/null); echo ; gettext -d mx-goodies -s "Report copied to system clipboard" ; CLOSE=$(gettext mx-goodies "Press any key to close"); read -n 1 -s -r -p "$CLOSE "'
Icon=face-devilish
Path=
Terminal=false
StartupNotify=false
Type=Application
Categories=System;
Code: Select all
System:
Host: mx Kernel: 4.15.0-1-amd64 x86_64 bits: 64 compiler: gcc v: 6.3.0
Desktop: Xfce 4.12.3 Distro: MX-18.2_x64 Continuum March 14 2018
base: Debian GNU/Linux 9 (stretch)
CPU:
Topology: Dual Core model: Intel Core i3 530 bits: 64
flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 23407
What was the problem, exactly?