5

Recently, a side-channel attack was discovered that exploits lazy FPU state switching to leak the contents of MMX, SSE, and AVX registers. The vulnerability can only be exploited when lazy FPU saves are used, as opposed to eager FPU saves. I am reading conflicting sources as to whether or not the Linux kernel is vulnerable. One source asserts that it is vulnerable. However, there is another resource from 2016 which explains that Linux uses eager FPU switching by default, indicating that it is unaffected. A commit from 2016 shows when eager switching became default.

Is Linux vulnerable, or is it not affected due to the use of eager FPU switching? My understanding is that it is vulnerable only if eagerfpu=off, which is not the default. Is my understanding correct?

2

Kernel versions prior to the patch you've shown are affected. For example this RedHat security bullentin states:

  • RHEL-7 will automatically default to (safe) “eager” floating point register restore on Sandy Bridge and newer Intel processors. AMD processors are not affected.

  • You can mitigate this issue on older processors by booting the kernel with the eagerfpu=on parameter to enable eager FPU restore mode. In this mode FPU state is saved and restored for every task/context switch regardless of whether the current process invokes FPU instructions or not. The parameter does not affect performance negatively, and can be applied without adverse effects to processors that are not affected.

RHEL 6 and earlier are impacted by this CVE and do not provide the eagerfpu parameter. Red Hat will be releasing updates which will change the behavior.

This suggests that the patch will be backported to earlier kernels since it requires modifying the kernel itself rather than simply changing a parameter upon compilation.

2

To cite the information from Redhat:

RHEL-7 will automatically default to (safe) “eager” floating point register restore on Sandy Bridge and newer Intel processors. AMD processors are not affected. ... You can mitigate this issue on older processors by booting the kernel with the eagerfpu=on parameter to enable eager FPU restore mode

For Debian it looks like that lazyFP is fixed for anything using a 4.9 kernel or newer. Debian also links to the kernel commit message from 01/2016 where eagerfpu was enabled for all CPU by default.

As for other distributions one need to have a look which kernel is used, which patches are maybe applied and which configuration settings where used. There is simply no "the Linux" but instead lots of distributions which use different kernel versions with different patches and different settings etc.

  • 2
    "The Linux kernel" means the vanilla kernel from kernel.org using the default configuration, not a distribution-specific kernel with a unique configuration or out-of-tree patches. – forest Jun 15 '18 at 6:37
0

Mostly yes they are.

Linux OS Vendors are trying to play in defense and now they have presented multiple parameters that you can enable / disable when you wish to use special CPU instructions. It is their way of not having to patch constantly the kernel. IF it is vulnerable disable the parameter and move on...

To have the parameter available you require the latest kernel updates.

The ones that have the mitigation enabled by default like red hat, are restricted to specific set of processors. They are automatically mitigated if this specific CPU is found. If not found they will fail over to off.

So you will need to check what is your Linux Flavor, what is your CPU and what is the kernel you are using to know if you are mitigated.

  • I don't think it's true that it is automatically mitigated only if the specific CPU is found. Any CPU that supports efficient eager FPU state switching seems to have it enabled by default since 2016, even before the bug was found. – forest Jun 19 '18 at 3:02
  • RHEL-7 will automatically default to (safe) “eager” floating point register restore on Sandy Bridge and newer Intel processors. AMD processors are not affected. – Hugo Jun 19 '18 at 11:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.