January 16, 20188 yr Author 30 minutes ago, thorloki said: Here's a good summary of Meltdown and Spectre flaws Informative video. Every PC I own needs to be replaced because the mobos are EOL. Make way for the class action lawsuits.
January 16, 20188 yr Good place to monitor progress in addressing this: https://github.com/hannob/meltdownspectre-patches
January 17, 20188 yr New linux kernel out with more fixes. 4.14.14 Retpoline support built in to mitigate against the Spectre vulnerability. Bring on 6.4.1
January 18, 20188 yr Hard to know if the link is legitimate, but based on the Spectre concept, it feels like there must be possible to find a hundred different way you can trick the processor into touching cache lines and then decode which lines was touched. So I'm pretty sure there will drop in quite a number of new vulnerabilities. I think the processors would need a way to regularly randomize the cache hash mapping so it isn't possible for a software module to analyze which address will touch a specific cache line and then make use of that information before the processor has switched to a different mapping. The disadvantage with such a solution would be that the processor has to regularly evict parts of the cache as it remaps. But as long as the remapping can be rotating and not need to invalidate every cache line at the same time, it shouldn't affect the total performance very much and the eviction shouldn't produce too large load spikes.
January 19, 20188 yr On 1/16/2018 at 9:55 AM, Joseph said: Informative video. Every PC I own needs to be replaced because the mobos are EOL. Make way for the class action lawsuits. Actually a lot of misinformation in there, post removed.
January 19, 20188 yr Author 1 hour ago, limetech said: Actually a lot of misinformation in there, post removed. So you reckon I don't have to worry about updating the BIOS then?
January 19, 20188 yr 19 minutes ago, Joseph said: So you reckon I don't have to worry about updating the BIOS then? You should if possible, but linux has a feature called Early Load Microcode which will update the microcode in your CPU if a microcode update is available for it.
January 19, 20188 yr 28 minutes ago, limetech said: You should if possible, but linux has a feature called Early Load Microcode which will update the microcode in your CPU if a microcode update is available for it. Is the microcode update performed with each boot? Or does or permanently update the processor when you boot with it if it is newer than the current microcode? If it's permanent, can it be backed out to prior version of it gives trouble?
January 19, 20188 yr 6 minutes ago, SSD said: Is the microcode update performed with each boot? Or does or permanently update the processor when you boot with it if it is newer than the current microcode? If it's permanent, can it be backed out to prior version of it gives trouble? Each boot. Same if done via bios - that is, if bios contains an updated microcode patch it gets loaded every time motherboard resets - you just don't see it happening.
January 19, 20188 yr 35 minutes ago, SSD said: Is the microcode update performed with each boot? Or does or permanently update the processor when you boot with it if it is newer than the current microcode? If it's permanent, can it be backed out to prior version of it gives trouble? The microcode is stored and run in volatile memory in the processor - nonvolatile memory isn't fast enough. And it was originally the BIOS task to be the boot loader not only for the complete machine but also for the configuration that needs to be loaded in the processor, the chipset etc. But it's great that the big chip manufacturer also supports late loading of microcode from the OS, allowing people with too old motherboards to get BIOS updates - or people too lazy to look for BIOS updates - to also get access to critical chip fixes.
January 20, 20188 yr 4 hours ago, limetech said: Each boot. Same if done via bios - that is, if bios contains an updated microcode patch it gets loaded every time motherboard resets - you just don't see it happening. Another question - if the unRAID server has updated microcode, does that cover all VMs as well?
January 20, 20188 yr 1 minute ago, SSD said: Another question - if the unRAID server has updated microcode, does that cover all VMs as well? Yes but individual OS's inside the VM's will need their individual patches.
January 20, 20188 yr On 1/16/2018 at 1:26 PM, limetech said: Good place to monitor progress in addressing this: https://github.com/hannob/meltdownspectre-patches I found a script linked that allows you to check if your Linux is vulnerable. I ran it on my server (which I have NOT YET UPDATED to 6.4 stable). I am in the process of building a new server which is currently in pieces, and it is on 6.4 stable, but can't run the script at this time. Will post results tomorrow on new server. Here is the result of running the script on an earlier 6.4 beta, which is vulnerable (came out long before any discussion of Spectre or Meltdown). Checking for vulnerabilities against running kernel Linux 4.11.6-unRAID #2 SMP PREEMPT Fri Jun 23 11:54:14 PDT 2017 x86_64 CPU is Intel(R) Xeon(R) CPU E3-1270 v3 @ 3.50GHz We're missing some kernel info (see -v), accuracy might be reduced CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1' * Checking count of LFENCE opcodes in kernel: UNKNOWN > STATUS: UNKNOWN (couldn't check (missing 'readelf' tool, please install it, usually it's in the 'binutils' package)) CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2' * Mitigation 1 * Hardware (CPU microcode) support for mitigation * The SPEC_CTRL MSR is available: NO * The SPEC_CTRL CPUID feature bit is set: NO * Kernel support for IBRS: NO * IBRS enabled for Kernel space: NO * IBRS enabled for User space: NO * Mitigation 2 * Kernel compiled with retpoline option: UNKNOWN (couldn't read your kernel configuration) * 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): NO * PTI enabled and active: NO * Checking if we're running under Xen PV (64 bits): NO > STATUS: VULNERABLE (PTI is needed to mitigate the vulnerability) A false sense of security is worse than no security at all, see --disclaimer
January 20, 20188 yr 26 minutes ago, SSD said: I found a script linked that allows you to check if your Linux is vulnerable ( note: this is kind of risky, only do this if you trust https://github.com/speed47/spectre-meltdown-checker ) How to install the script (will go away when you reboot) cd /tmp wget https://mirrors.slackware.com/slackware/slackware64-current/slackware64/d/binutils-2.29.1-x86_64-1.txz installpkg binutils-2.29.1-x86_64-1.txz wget https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh chmod 777 spectre-meltdown-checker.sh ./spectre-meltdown-checker.sh Results on 6.4.0: Spectre and Meltdown mitigation detection tool v0.31 Checking for vulnerabilities against running kernel Linux 4.14.13-unRAID #1 SMP PREEMPT Wed Jan 10 10:27:09 PST 2018 x86_64 CPU is Intel(R) Xeon(R) CPU E3-1240 v3 @ 3.40GHz We're missing some kernel info (see -v), accuracy might be reduced CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1' * Checking count of LFENCE opcodes in kernel: NO > STATUS: VULNERABLE (only 27 opcodes found, should be >= 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: UNKNOWN (couldn't read your kernel configuration) * 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 Edited January 20, 20188 yr by ljm42
January 20, 20188 yr 52 minutes ago, ljm42 said: ( note: this is kind of risky, only do this if you trust https://github.com/speed47/spectre-meltdown-checker ) How to install the script (will go away when you reboot) cd /tmp wget https://mirrors.slackware.com/slackware/slackware64-current/slackware64/d/binutils-2.29.1-x86_64-1.txz installpkg binutils-2.29.1-x86_64-1.txz wget https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh chmod 777 spectre-meltdown-checker.sh ./spectre-meltdown-checker.sh Results on 6.4.0: Spectre and Meltdown mitigation detection tool v0.31 Checking for vulnerabilities against running kernel Linux 4.14.13-unRAID #1 SMP PREEMPT Wed Jan 10 10:27:09 PST 2018 x86_64 CPU is Intel(R) Xeon(R) CPU E3-1240 v3 @ 3.40GHz We're missing some kernel info (see -v), accuracy might be reduced CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1' * Checking count of LFENCE opcodes in kernel: NO > STATUS: VULNERABLE (only 27 opcodes found, should be >= 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: UNKNOWN (couldn't read your kernel configuration) * 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 This has been posted somewhere else on the forum. It's showing that Meltdown vulnerability is in place. It's showing Sectre vulnerabilities are still a work in process (on all distros btw, not just unRAID - as of date of this post). 6.4.1 release uses 4.14.14 kernel which has "retpoline" patches BUT not actually compiled in because it requires GCC 7.3 also not yet pubilc: https://gcc.gnu.org/ml/gcc/2018-01/msg00114.html Full Spectre mitigation is going to take a while. Some are saying full recompile of all user-space programs will be necessary. This is my understanding anyway.
January 20, 20188 yr 8 hours ago, limetech said: This has been posted somewhere else on the forum. It's showing that Meltdown vulnerability is in place. It's showing Sectre vulnerabilities are still a work in process (on all distros btw, not just unRAID - as of date of this post). 6.4.1 release uses 4.14.14 kernel which has "retpoline" patches BUT not actually compiled in because it requires GCC 7.3 also not yet pubilc: https://gcc.gnu.org/ml/gcc/2018-01/msg00114.html Full Spectre mitigation is going to take a while. Some are saying full recompile of all user-space programs will be necessary. This is my understanding anyway. Wow! What a nightmare. I had another unrelated question that others might also be asking. If Linux is providing a means of loading the microcode, I am assuming Windows 7-10, and MacOS will do the same. If so, is there a strong requirement that the motherboard manufacturers of older motherboards provide BIOS updates? So long as you are using an OS that has the microcode, the system should be secured to basically the same level as a MB that has a BIOS update. Am I missing something? (Thinking about this myself, if there was some boot virus that was able to take control of the system prior to the OS load, I suppose it could interfere with microcode update. Seems a very small add'l risk on the OS update method. Anti-virus should largely prevent such a situation. Moreover, I don't consider this a big enough risk to cause people to dump older motherboards, but I may be missing something.)
January 22, 20188 yr On 1/20/2018 at 12:30 AM, limetech said: This has been posted somewhere else on the forum. It's showing that Meltdown vulnerability is in place. It's showing Sectre vulnerabilities are still a work in process (on all distros btw, not just unRAID - as of date of this post). 6.4.1 release uses 4.14.14 kernel which has "retpoline" patches BUT not actually compiled in because it requires GCC 7.3 also not yet pubilc: https://gcc.gnu.org/ml/gcc/2018-01/msg00114.html Full Spectre mitigation is going to take a while. Some are saying full recompile of all user-space programs will be necessary. This is my understanding anyway. This post says this Wednesday GCC 7.3 final will be out. https://gcc.gnu.org/ml/gcc/2018-01/msg00124.html
January 22, 20188 yr 37 minutes ago, Dazog said: This post says this Wednesday GCC 7.3 final will be out. https://gcc.gnu.org/ml/gcc/2018-01/msg00124.html Nice, thanks.
February 10, 20188 yr Kernel 4.14.18 https://lkml.org/lkml/2018/2/7/704 https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.18 Has ALOT of clean up and fixes for meltdown and spectre. FYI Edited February 10, 20188 yr by Dazog
February 22, 20188 yr Update on Spectre remediation from Intel. Concise description that helps better understand Spectre and the fixes. https://arstechnica.com/gadgets/2018/02/intel-ships-hopefully-stable-microcode-for-skylake-kaby-lake-coffee-lake/
February 22, 20188 yr 2 hours ago, SSD said: Update on Spectre remediation from Intel. Concise description that helps better understand Spectre and the fixes. There has been no change to microcode download available for linux "early microcode loading", still latest is from last November: https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File?product=873 If your motherboard manufacturer has not released new bios, no new microcode for you!
February 22, 20188 yr here is the latest from intel on what you should upgrade/when your upgrade is coming: https://newsroom.intel.com/wp-content/uploads/sites/11/2018/02/microcode-update-guidance.pdf
Archived
This topic is now archived and is closed to further replies.