On Wed, 4 Mar 2020 at 14:19, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Wed, Mar 04, 2020 at 09:47:02AM +0100, Greg Kroah-Hartman wrote:
On Wed, Mar 04, 2020 at 09:11:28AM +0100, Greg Kroah-Hartman wrote:
On Wed, Mar 04, 2020 at 12:43:42PM +0530, Naresh Kamboju wrote:
On Tue, 3 Mar 2020 at 23:16, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 5.5.8 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 05 Mar 2020 17:42:06 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.5.8-rc1.g... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.5.y and the diffstat can be found below.
thanks,
greg k-h
Results from Linaro’s test farm. Regressions detected on x86_64 and i386.
Test failure output: CVE-2017-5715: VULN (IBRS+IBPB or retpoline+IBPB+RSB filling, is needed to mitigate the vulnerability)
Test description: CVE-2017-5715 branch target injection (Spectre Variant 2)
Impact: Kernel Mitigation 1: new opcode via microcode update that should be used by up to date compilers to protect the BTB (by flushing indirect branch predictors) Mitigation 2: introducing "retpoline" into compilers, and recompile software/OS with it Performance impact of the mitigation: high for mitigation 1, medium for mitigation 2, depending on your CPU
So these are regressions or just new tests?
If regressions, can you do 'git bisect' to find the offending commit?
Also, are you sure you have an updated microcode on these machines and a proper compiler for retpoline?
As an example of just how crazy that script is, here's the output of my machine for that first CVE issue:
CVE-2017-5715 aka 'Spectre Variant 2, branch target injection'
- Mitigated according to the /sys interface: YES (Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling)
- Mitigation 1
- Kernel is compiled with IBRS support: YES
- IBRS enabled and active: YES (for firmware code only)
- Kernel is compiled with IBPB support: YES
- IBPB enabled and active: YES
- Mitigation 2
- Kernel has branch predictor hardening (arm): NO
- Kernel compiled with retpoline option: YES
- Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
- Kernel supports RSB filling: UNKNOWN (couldn't check (couldn't find your kernel image in /boot, if you used netboot, this is normal))
STATUS: VULNERABLE (IBRS+IBPB or retpoline+IBPB+RSB filling, is needed to mitigate
So why is this "Vulnerable"? Because it didn't think it could find my kernel image for some odd reason, despite it really being in /boot/ (I don't use netboot)
Now I know the real reason why this test failed. With this note we can conclude this is not a regression.
No regressions on arm64, arm, x86_64, and i386 for 4.19, 5.4 and 5.5 branches.
Sorry for the noise.