18

As for the "Spectre" security vulnerability, "Retpoline" was introduced to be a solution to mitigate the risk. However, I've read a post that mentioned:

If you build the kernel without CONFIG_RETPOLINE, you can't build modules with retpoline and then expect them to load — because the thunk symbols aren't exported.

If you build the kernel with the retpoline though, you can successfully load modules which aren't built with retpoline. (Source)

Is there an easy and common/generic/unified way to check if kernel is "Retpoline" enabled or not? I want to do this so that my installer can use the proper build of kernel module to be installed.

22

If you’re using mainline kernels, or most major distributions’ kernels, the best way to check for full retpoline support (i.e. the kernel was configured with CONFIG_RETPOLINE, and was built with a retpoline-capable compiler) is to look for “Full generic retpoline” in /sys/devices/system/cpu/vulnerabilities/spectre_v2. On my system:

$ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
Mitigation: Full generic retpoline, IBPB, IBRS_FW

If you want more comprehensive tests, to detect retpolines on kernels without the spectre_v2 systree file, check out how spectre-meltdown-checker goes about things.

  • 2
    To check for other meltdown/spectre-related vulnerabilities as well, run $ grep . /sys/devices/system/cpu/vulnerabilities/*, which is suggested in Greg Kroah-Hartman's blog. – Alex Vong Apr 6 '18 at 6:01
  • 1
    Thanks @Alex; I was answering the specific question, but that is useful — although I prefer head /sys/devices/system/cpu/vulnerabilities/* myself ;-). That currently covers Meltdown/Spectre vulnerabilities, but should also cover any future vulnerabilities of a similar nature (the namespace is purposefully generic). – Stephen Kitt Apr 6 '18 at 6:56
  • @StephenKitt Yeah, head gives a nicer formatted output. – Alex Vong Apr 6 '18 at 17:11
4

Stephen Kitt's answer is more comprehensive in this specific case, because the retpoline support also needs new compiler version.

But in general case, most distributions have the kernel configuration file available in one of the following locations:

  • /boot/config-4.xx.xx-...
  • /proc/config.gz

Then you can simply zgrep CONFIG_RETPOLINE /boot/config* /proc/config.gz

  • 4
    I recommend against grepping in /boot/config*, because that may find CONFIG_RETPOLINE in a kernel image which is installed but not currently running, giving a false sense of security. Examining /proc/config.gz or /sys/... is safe, but many Linux distributions compile the kernel without /proc/config.gz. – pts Apr 5 '18 at 22:00
  • Could you make the logic a bit smarter and use uname (or the equivalent syscall) to get the currently running kernel and then examine that particular /boot/config file? – Adam Luchjenbroers Apr 6 '18 at 0:52
  • @pts /boot/config-$(uname -r), then? – muru Apr 6 '18 at 3:45
  • 2
    Using /boot/config-$(uname -r) isn’t fool-proof either: it still doesn’t guarantee that the config matches the running kernel. Distro kernels keep the same uname -r across multiple versions, as long as the kernel ABI doesn’t change. – Stephen Kitt Apr 6 '18 at 4:17
  • Thank you all for your reply. Your answer and message is helpful. – Weishan Yang Apr 6 '18 at 8:06

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.