Test failure on 4.14.154-grsec-securedrop using NUC7i7DNHE

[rocodes]

Description

Running Meltdown tests (https://meltdown.ovh/) on NUC7i7DNHE with 4.14.154-grsec-securedrop kernel leads to a failure for CVE-2018-3615 (Foreshadow SGX).

This has been tested on BIOS version 0066 and 0067 (most recent).

Steps to Reproduce

Run meltdown test script at https://meltdown.ovh/ as sudo on NUC7i7DHNE. Note: only try this on non production (QA) machines!

Expected Behavior

No failures

Actual Behavior

2 vulnerabilities: One with Spectre v2 (CVE-2017-5715), which can be remediated by installing binutils (remediation approved by @emkll).

The second:

CVE-2018-365` aka 'Foreshadow (SGX), L1 terminal fault'
* CPU microcode mitigates the vulnerability: NO
> STATUS:  VULNERABLE  (your CPU supports SGX and the microcode is not up to date)

Comments

Needs reproducing

[sssoleileraaa]

I repro'd, seeing 2 vulnerabilities:

1. Branch target injection vulnerability needs mitigation

CVE-2017-5715 aka 'Spectre Variant 2, branch target injection'
...
> STATUS:  VULNERABLE  (IBRS+IBPB or retpoline+IBPB+RSB filling, is needed to mitigate the vulnerability)

2. CPU microcode is not up to date

CVE-2018-365` aka 'Foreshadow (SGX), L1 terminal fault'
* CPU microcode mitigates the vulnerability: NO
> STATUS:  VULNERABLE  (your CPU supports SGX and the microcode is not up to date)

[rocodes]

(@creviera just mentioned that, as in my case, installing binutils remediates the first issue, CVE-2017-5715)

[emkll]

Thanks @rocodes for all your help in debugging this issue and @creviera for reproducing. After some investigation, we've come to the following conclusion: because the test is passing on a vanilla kernel, and that the mitigation is only microcode, and that we use the exact same microcode (both bios and deb package), this failure is a very likely a false positive, as the script cannot detect that we have the CPU features introduced for other L1TF mitigations (CVE-2018-3620) due to the grsecurity mitigations in place.

The reason we have not seen this before is that not many of us have modern i7 CPUs for testing which is why we haven't seen it before.

The test for CVE-2018-3615 is somewhat unreliable, as described in the comments (https://github.com/speed47/spectre-meltdown-checker/blob/6e799e8b013c6543c5d1fef3f7d69ce172a9ff52/spectre-meltdown-checker.sh#L4359-L4367).

The primary detection method for detection is accessing MSR get information about presence of the flush command. However this is blocked on our grsecurity kernel due to GRKERNSEC_KMEM being set, preventing /dev/kmem and /dev/mem from reading/writing kernel memory.

It's unclear why they don't use the full CVE-2018-3620 test as part of the CVE-2018-3613, likely to keep it self-contained. The former uses the more reliable (at least under grsecurity) method of reading /proc/cpuinfo instead of directly from the device /dev/cpu/ which is likely locked down by grsecurity.

Furthermore, testing on VMs ( with the 4.14.154 kernel, though with CPU marked not vulnerable), i can reproduce the l1 flush check failing (failing as in returning an inconclusive result blue text N/A, not yellow NO as in not present), but the test passes due to the CPU not having SGX support.

Given that the test passed in the vanilla kernel, that we are using the exact same microcode package, and that /proc/cpuinfo returns flush_l1tf as supported features, we can safely assume that the systems are patched for that vulnerability, and is a false positive due to the locked down nature of our kernels.

[redshiftzero]

Furthermore, testing on VMs ( with the 4.14.154 kernel, though with CPU marked not vulnerable), i can reproduce the l1 flush check failing (failing as in returning an inconclusive result blue text N/A, not yellow NO as in not present), but the test passes due to the CPU not having SGX support.

This is what I see in VMs also. Also the theory about MSR makes sense, I see this when I'm running the spectre-meltdown-checker.sh script in a SD VM:

[ 483.081058] grsec: From 10.0.1.1: denied write to CPU MSR by /usr/bin/perl[perl:5111] uid/euid:0/0 gid/egid:0/0, parent /home/vagrant/spectre-meltdown-checker.sh[spectre-meltdow:4964] uid/euid:0/0 gid/egid:0/0

It looks like this denial isn't handled by the script to set msr_locked_down=1 (they're looking for a specific string msr: Direct access to MSR) hence the false positive.

Regarding CVE-2017-5715 for posterity I'm noting that binutils was required for that test, which is why installing resolved. From that test run on i7 (h/t @creviera for providing this):

Kernel supports RSB filling: UNKNOWN (missing 'strings' tool, please install it, usually it's in the binutils package)