Security flaw discovered in Intel chips.


Joseph

Recommended Posts

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.

Link to comment
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?

Link to comment
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.

Link to comment
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.

Link to comment
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?

Link to comment
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

 

Link to comment
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 by ljm42
Link to comment
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.

  • Like 1
  • Upvote 1
Link to comment
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.)

Link to comment
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

 

 

Link to comment
  • 3 weeks later...
  • 2 weeks later...
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!

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.