Spectre v1 fix not detected on ARM

[V10lator]

This is on ARM, not ARM64.

[speed47]

Last time I checked (weeks ago, so it might have changed), the fix for non-64 ARM wasn't ready yet. What is the kernel version you're using so I can check the source code?

[V10lator]

It should be in 4.18 (see https://www.phoronix.com/scan.php?page=news_item&px=Spectre-32-bit-ARM-Linux-4.18 ) - I for myself am using a 4.4 kernel with backports specially designed for a SBC: https://github.com/V10lator/CHIP-linux/tree/4.4.13-v10

//EDIT: The commits fixing spectre v1/v2 should be the commits made at Jun 11, 2018 from here: https://github.com/V10lator/CHIP-linux/commits/4.4.13-v10?after=cd8fbfdd8ee9b1e4fa27b6b81e60f4911bc81863+0

[kostapr]

I have to patch my release, which is based on 4.4.52 kernel and hopefully will make use of patches from CHIP-linux project. So I vote for 4.4 kernel support with Spectre-1/2 patches on ARMv7 platform. Will be nice to have the Spectre-1 mitigation detected by the script. BTW Spectre-2 mitigation is reported in kernel log already:

[ 0.000502] CPU: Testing write buffer coherency: ok [ 0.000512] CPU0: Spectre v2: using BPIALL workaround [ 0.000599] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.000619] Setting up static identity map for 0x8280 - 0x82d8 [ 0.000764] mvebu-soc-id: MVEBU SoC ID=0x6820, Rev=0x4 [ 0.000847] mvebu-pmsu: Initializing Power Management Service Unit [ 0.001271] Booting CPU 1 [ 0.001372] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001 [ 0.001374] CPU1: Spectre v2: using BPIALL workaround [ 0.001404] Brought up 2 CPUs [ 0.001408] SMP: Total of 2 processors activated (100.00 BogoMIPS).

[speed47]

Can you check the arm branch? It should detect it now on ARM arch (not ARM64, which was already implemented)

[speed47]

This has been included in the v0.38 release, to avoid delaying it further. Please comment if you can confirm it works as expected under a native ARM 32 system (not arm64)

[hpatel2]

Hi Konstantin Porotchkin, We are using kernel version 4.18-rc8 and gcc version 8.1 for our ARM32 based Cortex A8 processor. But still this script is showing spectre-v1 as vulnerable. Did you found any other patches/configuration of kernel/gcc that can be shown spectre-v1 as NOT Vulnerable with this script? Thanks.

[speed47]

The script detects kernels containing those commits for spectre-v1 http://git.arm.linux.org.uk/cgit/linux-arm.git/log/?h=spectre, these are the same than the ones @V10lator was pointing out (https://github.com/V10lator/CHIP-linux/commits/4.4.13-v10?after=cd8fbfdd8ee9b1e4fa27b6b81e60f4911bc81863+0). These are also included in v4.18-rc8.

I don't have a native ARM system to test it, but a cross-compiled kernel says:

$ ./spectre-meltdown-checker.sh --kernel vmlinux --variant 1 --arch-prefix arm-none-eabi-
Spectre and Meltdown mitigation detection tool v0.38

Checking for vulnerabilities against specified kernel
CPU is Intel(R) Pentium(R) CPU G3420 @ 3.20GHz
We're missing some kernel info (see -v), accuracy might be reduced
Kernel image is Linux version 4.18.0-rc8 (speed@nas) (gcc version 4.9.3 20150529 (prerelease) (15:4.9.3+svn231177-1)) #1 Thu Aug 9 14:18:53 CEST 2018

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Kernel has array_index_mask_nospec:  YES  (4 occurrence(s) found of arm 32 bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch:  NO 
* Kernel has mask_nospec64 (arm64):  NO 
> STATUS:  NOT VULNERABLE  (Kernel source has been patched to mitigate the vulnerability (arm 32 bits array_index_mask_nospec))

Need more detailed information about mitigation options? Use --explain
A false sense of security is worse than no security at all, see --disclaimer

In your .config, do you have CPU_SPECTRE defined ?

[hpatel2]

Hi,

Thank you for providing feedback. In my kernel configuration, there was support enabled for ARM arch v6 and v7 both. I have disabled support for v6 and then the script is showing status as NOT Vulnerable on my ARM device. I don't know why v6 support was stopping this script to identify spectre-v1 fixes.

Still, I have below 3 confusions. It would be great if you help me to clarify it.

1. I am passing vmlinux kernel image (size is 117MB) which is present under my Linux kernel home directory {KERNEL_SOURCE}/vmlinux. Is this correct image that I need to pass to this script? If I pass vmlinux image present on path {KERNEL_SOURCE}/arch/arm/boot/compressed/vmlinux (size is 5MB) then script is not able to detect spectre-v1 fix. Also I have tried to pass uImage, Image and zImage files present under {KERNEL_SOURCE}/arch/arm/boot directory and in all cases script is not able to identify spectre fixes.

2. Currently, I am using GCC version 4.9.2 to cross compile my Linux kernel. In some threads, I read that we also need to upgrade GCC version to fix spectre-v1 and v2 issues. Is this correct?

3. In my case spectre checker script is giving below output for spectre-v2 check: CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'

• Mitigation 1
  • Kernel is compiled with IBRS support: YES
    • IBRS enabled and active: N/A (not testable in offline mode)
  • Kernel is compiled with IBPB support: NO
    • IBPB enabled and active: N/A (not testable in offline mode)
• Mitigation 2
  • Kernel has branch predictor hardening (arm): YES
  • Kernel compiled with retpoline option: NO STATUS: NOT VULNERABLE (Branch predictor hardening mitigates the vulnerability)

I can see Mitigation 1 is passed for IBRS and not for IBPB support. Does it require to pass both (IBRS and IBPB) check in order to confirm spectre-v2 fix? Same is case with Mitigation 2, My kernel is not compiled with retpoline option.

Thanks.

[speed47]

1. the {KERNEL_SOURCE}/vmlinux file is probably the raw uncompressed and unprocessed kernel image file, straight out from compilation/linking and before compression/packing/formatting (arch-dependent, uImage doesn't exist on x86 for example), so this is a good source. Detection should have worked with the compressed one however, if you run the script with -v mode, you might have messages about the impossibility to extract the kernel image you passed as parameter. Yet more details are available in -v -v mode. When you're using the script offline as you do, with --kernel, don't forget to add --config and --map, pointing to the corresponding files, the script needs those for some detections.

2. A very recent GCC is only needed for retpoline mitigation AFAIK, this is one of the mitigations for spectre v2.

3. IBRS and IBPB are x86 mitigations, that's even strange the script detected IBRS in your vmlinux file! If you're sure the vmlinux file doesn't come from a previous compilation under x86, I might be interested to have a look at it, because that doesn't feel right. Branch predictor hardening is enough under ARM to mitigate spectre v2, which is why "not vulnerable" is reported in your case. Under x86 this is way more complicated, depending on your CPU, and the script does detect that automatically, but you need a mix of (full) retpoline and/or IBRS and/or IBPB to mitigate.

[hpatel2]

Hi, Thank you for providing feedback on my queries. As suggested by you, the script should show status as not vulnerable with vmlinux present under {KERNEL_SOURCE}/arch/arm/boot/compressed/ path (Size 5MB) but in my case script is not showing expected result with this image. If I take vmlinux image from {KERNEL_SOURCE}/vmlinux (size 117MB) then the only script is able to provide spectre-v1 status as NOT vulnerable.

I have also checked this on my x86 machine by providing --arch-prefix with arm toolchain but the result is same. Does it work properly on your x86 machine if you provide vmlinux from {KERNEL_SOURCE}/arch/arm/boot/compressed/ path? What is vmlinux image size in your case?

Also I am passing .config and System.map file to script. Please find attached file for complete output from script. Please let me know what should I do further to get correct output from vmlinux present under {KERNEL_SOURCE}/arch/arm/boot/compressed/ path.

script_output.txt

[hpatel2]

Hi,

It would be helpful for us if you can confirm about vmlinux image path as suggested in above comment.

Thanks,