search

speed47 / spectre-meltdown-checker

Reptar, Downfall, Zenbleed, ZombieLoad, RIDL, Fallout, Foreshadow, Spectre, Meltdown vulnerability/mitigation checker for Linux & BSD
3.87k stars 476 forks source link

CVE-2018-3615:KO shows microcode not up to date, when, in fact, it is #296

Open eris23 opened 5 years ago

eris23 commented 5 years ago

I've been exploring this problem at https://answers.launchpad.net/ubuntu/+source/intel-microcode/+question/681827. It doesn't seem to be a problem on the Ubuntu side. Is this being falsely flagged?

lilyanatia commented 5 years ago

your CPU apparently has:

    * FLUSH_CMD MSR is available: NO
    * CPU indicates L1D flush capability: YES (L1D flush feature bit)

and the script currently does:

        _info_nol "* CPU microcode mitigates the vulnerability: "
        if [ "$cpu_flush_cmd" = 1 ] && [ "$cpuid_sgx" = 1 ]; then
                # no easy way to detect a fixed SGX but we know that
                # microcodes that have the FLUSH_CMD MSR also have the
                # fixed SGX (for CPUs that support it)
                pstatus green YES
        elif [ "$cpuid_sgx" = 1 ]; then
                pstatus red NO
        else
                pstatus blue N/A
        fi

maybe the script should use the L1D flush feature bit instead of the FLUSH_CMD MSR to determine whether CVE-2018-3615 is mitigated?

eris23 commented 5 years ago

Well...as of today it still says:

CVE-2018-3615 aka 'Foreshadow (SGX), L1 terminal fault'

cat /proc/cpuinfo shows:

processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 142 model name : Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz stepping : 9 microcode : 0xb4 ... bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds

uname -a shows:

Linux Tablet 5.2.0-8-lowlatency #9-Ubuntu SMP PREEMPT Mon Jul 8 13:49:06 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Katzeilla commented 5 years ago

Are you root?

As for me, run this scrpt with root privileges will fix this issue. :)

eris23 commented 5 years ago

Same problem. Run as root:

CVE-2018-3615 aka 'Foreshadow (SGX), L1 terminal fault'

gaul commented 5 years ago

On my system this check fails due to check_CVE_2018_3615 relying on the value of cpu_flush_cmd which is not populated due to:

wrmsr: pwrite: Operation not permitted

StackOverflow suggests that disabling SecureBoot may work around this. Is there any other way to check for this?

Ancillius commented 5 years ago

Can confirm on Debian Sid: spectre-meltdown-checker: Installed: 0.42-2

CVE-2018-3615 aka 'Foreshadow (SGX), L1 terminal fault'

Kernel is Linux 5.3.0-2-amd64 #1 SMP Debian 5.3.9-2 (2019-11-12) x86_64 CPU is Intel(R) Core(TM) i5-8600K CPU @ 3.60GHz

martywd commented 5 years ago

Yup, this has been an issue for me with all the 5.3.x kernels as well, but NOT with 5.2.x or 4.15.x kernels.

Examples, all from the same machine running an ubuntu 18.04 variant w/ intel-microcode 3.20191112-0ubuntu0.18.04.2 (edited to add: Secure Boot is disabled on this machine)

Booted into 5.3.11-050311-generic I get the 'CVE-2018-3615:KO' (VULNERABLE) https://termbin.com/yulrv

Booted into 5.2.21-050221-generic -- 'CVE-2018-3615:OK' (NOT VULNERABLE) https://termbin.com/2nbe

And finally, also on the same machine, booted into kernel 4.15.0-70-generic -- 'CVE-2018-3615:OK' (NOT VULNERABLE) https://termbin.com/gvofi

.

speed47 commented 5 years ago

@martywd 's issue root cause was different and has been fixed in #316 . For the others: can you try the latest master branch? If the result doesn't seem right, please post the output of the script in very verbose mode using -v -v), thanks!

Ancillius commented 5 years ago

The current master seems to fix it:

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 CVE-2019-11135:OK

(no changes to the kernel/microcode)

Would be a pleasure to get this to debian sid asap (dunno whos the maintainer there).

ilikenwf commented 5 years ago

I also am seeing kernel lockdown mode set to max breaking this because it prevents MSR writing.

gaul commented 5 years ago

This still fails for me with 6e799e8b013c6543c5d1fef3f7d69ce172a9ff52 and Linux 5.3.12-300.fc31.x86_64:

SUMMARY: CVE-2017-5753:OK CVE-2017-5715:OK CVE-2017-5754:OK CVE-2018-3640:OK CVE-2018-3639:OK CVE-2018-3615:KO CVE-2018-3620:OK CVE-2018-3646:OK CVE-2018-12126:OK CVE-2018-12130:OK CVE-2018-12127:OK CVE-2019-11091:OK CVE-2019-11135:OK CVE-2018-12207:OK

speed47 commented 5 years ago

Do any of you @ilikenwf or @gaul (or both!) run the script with -v -v and post the output? This would help pinpointing the problem. I'd like to fix this before releasing the next version. Thanks!

ilikenwf commented 5 years ago

I'm not sure it's the same issue - but the lockdown feature, if enabled, has multiple options...

In the highest setting, the MSRs can't be unlocked via LSM, in the next highest, in theory, a proper LSM policy manager (apparmor etc) could allow access for spectre-meltdown-checker.

It needs some reworking, I think, to allow whitelisting of specific registers. I have a thread going on the linux-security-module mailing list right now about it.

On 12/2/19 1:00 PM, Stéphane Lesimple wrote:

Do any of you @ilikenwf https://github.com/ilikenwf or @gaul https://github.com/gaul (or both!) run the script with |-v -v| and post the output? This would help pinpointing the problem. I'd like to fix this before releasing the next version. Thanks!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/speed47/spectre-meltdown-checker/issues/296?email_source=notifications&email_token=AADFIOTNM3SCFHY4FQ44FLLQWVLNXA5CNFSM4H6VOZ62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFUQ7YY#issuecomment-560533475, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADFIOVVLDTOWMDUORUBIUDQWVLNXANCNFSM4H6VOZ6Q.

gaul commented 4 years ago

With 0cd7e1164f1ebcbcc13484fe1b1218f1154ecbb2 spectre-meltdown-checker reports:

  * L1 data cache invalidation
    * FLUSH_CMD MSR is available:  UNKNOWN  (your kernel is locked down (Fedora/Red Hat), please reboot without secure boot and retry)
...
> 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 CVE-2019-11135:OK CVE-2018-12207:OK
speed47 commented 4 years ago

When lockdown is detected (either by the Red Hat patch, or the more recent one that made it to vanilla in 5.4+ since 0cd7e11), the script only relies on CPUID and ignores the fact that it can't test the write-only MSRs. This should fix the issue indeed. After the next release, I'm planning to add a "side note" mecanism that'll display some messages at the end of the run, when applicable, and this choice of making the assumption that the MSR writes probably work under lockdown mode when the corresponding CPUID bit is set will be indicated there. It's important because it can be wrong under some specific circumstances, such as the script being run in a VM whose hypervisor exhibits the CPUID bit but not the MSR.

speed47 commented 4 years ago

This issue had a lot of reporters, can it be considered fixed with latest release?

Photon89 commented 2 years ago

Just ran into it. Maybe add something like "The analysis might be inaccurate due to permission problems, please run as root!" as last output line, if there are permission issues?

kjkent commented 3 months ago

Unfortunately it seems this issue is still present, or is present again (at least for me).

Running ./spex.sh --allow-msr-write --explain as root returns the unexpected result on my i5-8350u with latest microcode applied.