Retpoline?

Technical issues/questions of an intermediate or advanced nature.
Post Reply
User avatar
n0ctilucient
Shogun
Shogun
Posts: 329
Joined: 21 Apr 2017, 15:59
Distribution: fullmoonremix
Location: 127.0.0.1
Contact:

Retpoline?

Post#1 by n0ctilucient » 24 Feb 2018, 20:17

Perhaps I should be concerned...

Partial ouput of Dmesg on my X200 (coreboot) Thinkpad...

Code: Select all

[   96.447987] Spectre V2 : System may be vulnerable to spectre v2
[   96.447989] kvm_intel: loading module not compiled with retpoline compiler.
Is it time for a compiler update and recompiled modules?
If so... where should I start?
Last edited by n0ctilucient on 25 Feb 2018, 13:18, edited 1 time in total.
:hmmm: I do NOT have the "right" to tell anyone what they should do...
but I reserve the "right" to tell them what they should "consider".

beny
Full of knowledge
Full of knowledge
Posts: 740
Joined: 02 Jan 2011, 11:33
Location: italy

Retpoline?

Post#2 by beny » 24 Feb 2018, 23:59

bash-4.3# sh /root/spectre-meltdown-checker/spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.31

Checking for vulnerabilities against running kernel Linux 4.14.19-zen #1 ZEN SMP Sat Feb 17 00:17:19 CET 2018 x86_64
CPU is AMD FX(tm)-6300 Six-Core Processor

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking whether we're safe according to the /sys interface: YES (kernel confirms that the mitigation is active)
> STATUS: NOT VULNERABLE (Mitigation: __user pointer sanitization)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Checking whether we're safe according to the /sys interface: YES (kernel confirms that the mitigation is active)
> STATUS: NOT VULNERABLE (Mitigation: Full AMD retpoline)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Checking whether we're safe according to the /sys interface: YES (kernel confirms that your CPU is unaffected)
> STATUS: NOT VULNERABLE (Not affected)

A false sense of security is worse than no security at all, see --disclaimer
bash-4.3#
slackware 14.2 gcc 5.5.0 with the last slackware patch seem to work,maybe

User avatar
n0ctilucient
Shogun
Shogun
Posts: 329
Joined: 21 Apr 2017, 15:59
Distribution: fullmoonremix
Location: 127.0.0.1
Contact:

Retpoline?

Post#3 by n0ctilucient » 25 Feb 2018, 02:13

Thanks beny... it seems like AMD is the long term solution.
:hmmm: I do NOT have the "right" to tell anyone what they should do...
but I reserve the "right" to tell them what they should "consider".

raja
Samurai
Samurai
Posts: 121
Joined: 02 May 2017, 09:51
Distribution: v3.2.2-32 and v4.0-rc1-64
Location: Chennai,India

Retpoline?

Post#4 by raja » 25 Feb 2018, 08:38

I inject intel-ucode at boot. There is no instability problem with version x80, in my machine (advised by Intel). So happy to use that.
See this report by spectre cheaker v0.35, my machine looks clean.

Code: Select all

Spectre and Meltdown mitigation detection tool v0.35

Checking for vulnerabilities on current system
Kernel is Linux 4.15.3-porteus #1 SMP PREEMPT Fri Feb 16 13:11:51 UTC 2018 x86_64                                                                         
CPU is Intel(R) Core(TM) i3-7100U CPU @ 2.40GHz
We're missing some kernel info (see -v), accuracy might be reduced

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
  * Indirect Branch Restricted Speculation (IBRS)
    * SPEC_CTRL MSR is available:  YES 
    * CPU indicates IBRS capability:  YES  (SPEC_CTRL feature bit)
  * Indirect Branch Prediction Barrier (IBPB)
    * PRED_CMD MSR is available:  YES 
    * CPU indicates IBPB capability:  YES  (SPEC_CTRL feature bit)
  * Single Thread Indirect Branch Predictors (STIBP)
    * SPEC_CTRL MSR is available:  YES 
    * CPU indicates STIBP capability:  YES 
  * Enhanced IBRS (IBRS_ALL)
    * CPU indicates ARCH_CAPABILITIES MSR availability:  NO 
    * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability:  NO 
  * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO):  NO 
  * CPU microcode is known to cause stability problems:  YES  (model 142 stepping 9 ucode 0x80)

The microcode your CPU is running on is known to cause instability problems,
such as intempestive reboots or random crashes.
You are advised to either revert to a previous microcode version (that might not have                                                                     
the mitigations for Spectre), or upgrade to a newer one if available.

* CPU vulnerability to the three speculative execution attacks variants
  * Vulnerable to Variant 1:  YES 
  * Vulnerable to Variant 2:  YES 
  * Vulnerable to Variant 3:  YES 

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
* Kernel has array_index_mask_nospec:  UNKNOWN  (couldn't check (couldn't find your kernel image in /boot, if you used netboot, this is normal))
* Kernel has the Red Hat/Ubuntu patch:  UNKNOWN  (missing 'strings' tool, please install it, usually it's in the binutils package)
* Checking count of LFENCE instructions following a jump in kernel...  UNKNOWN  (couldn't check (couldn't find your kernel image in /boot, if you used netboot, this is normal))
> STATUS:  NOT VULNERABLE  (Mitigation: __user pointer sanitization)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
* Mitigation 1
  * Kernel is compiled with IBRS/IBPB support:  NO 
  * Currently enabled features
    * IBRS enabled for Kernel space:  NO 
    * IBRS enabled for User space:  NO 
    * IBPB enabled:  NO 
* Mitigation 2
  * Kernel compiled with retpoline option:  UNKNOWN  (couldn't read your kernel configuration)
  * Kernel compiled with a retpoline-aware compiler:  YES  (kernel reports full retpoline compilation)
> STATUS:  NOT VULNERABLE  (Mitigation: Full generic retpoline)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
* Kernel supports Page Table Isolation (PTI):  UNKNOWN  (couldn't read your kernel configuration nor System.map file)
* PTI enabled and active:  YES 
* Running as a Xen PV DomU:  NO 
> STATUS:  NOT VULNERABLE  (Mitigation: PTI)

A false sense of security is worse than no security at all, see --disclaimer
And with latest " site isolation" enabling provision in the browses ( source of entry for mischief creators), one can be assured of reasonable protection.

cheers
Linux Kernel-4.4.120-32 bit; Linux kernel-4.15.7-64 bit.

User avatar
n0ctilucient
Shogun
Shogun
Posts: 329
Joined: 21 Apr 2017, 15:59
Distribution: fullmoonremix
Location: 127.0.0.1
Contact:

Retpoline?

Post#5 by n0ctilucient » 25 Feb 2018, 13:16

Dmesg seems to imply many modules were not compiled with retpoline GCC.
:hmmm: I do NOT have the "right" to tell anyone what they should do...
but I reserve the "right" to tell them what they should "consider".

User avatar
brokenman
Site Admin
Site Admin
Posts: 5864
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v3.2rcX all desktops
Location: Brazil
Contact:

Retpoline?

Post#6 by brokenman » 28 Feb 2018, 23:53

Yes retpoline aware gcc is only a very recent thing in slackware. It is very possible that many modules were not compiled with it. The GCC version in Porteus-4.0+ is retpoline aware and I would imagine that any slackware kernel-firmware package after the release of Porteus-4.0 would also have been compiled with this.
How do i become super user?
Wear your underpants on the outside and put on a cape.

User avatar
n0ctilucient
Shogun
Shogun
Posts: 329
Joined: 21 Apr 2017, 15:59
Distribution: fullmoonremix
Location: 127.0.0.1
Contact:

Retpoline?

Post#7 by n0ctilucient » 01 Mar 2018, 13:26

A retpoline is designed to protect against the branch target injection (CVE-2017-5715) exploit.

A thought provoking discussion w/ detailed explanation and links...
-mindirect-branch=thunk-extern

see... https://stackoverflow.com/questions/480 ... es-it-work
I have the new GCC... perhaps all my problems will be
solved by adding the above parameter to my src2pkg config?

I assume this would fix all or most of the broken kernel modules.

However... would this not still require knowledge of hacking the kernel to install the "fixed" kernel modules?

Also... where would I download "kvm_intel" source?
Last edited by n0ctilucient on 05 Mar 2018, 10:06, edited 3 times in total.
:hmmm: I do NOT have the "right" to tell anyone what they should do...
but I reserve the "right" to tell them what they should "consider".

raja
Samurai
Samurai
Posts: 121
Joined: 02 May 2017, 09:51
Distribution: v3.2.2-32 and v4.0-rc1-64
Location: Chennai,India

Retpoline?

Post#8 by raja » 01 Mar 2018, 16:57

here you go for kvm_main.c;

https://github.com/torvalds/linux/blob/ ... kvm_main.c

Complete codes available under "virt" in Linux source.
Linux Kernel-4.4.120-32 bit; Linux kernel-4.15.7-64 bit.

User avatar
n0ctilucient
Shogun
Shogun
Posts: 329
Joined: 21 Apr 2017, 15:59
Distribution: fullmoonremix
Location: 127.0.0.1
Contact:

Retpoline?

Post#9 by n0ctilucient » 01 Mar 2018, 23:51

Thanks raja... :good:
:hmmm: I do NOT have the "right" to tell anyone what they should do...
but I reserve the "right" to tell them what they should "consider".

User avatar
brokenman
Site Admin
Site Admin
Posts: 5864
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v3.2rcX all desktops
Location: Brazil
Contact:

Retpoline?

Post#10 by brokenman » 02 Mar 2018, 00:49

The entire basis of modern day parallel computing has been exploited. This is not the end of 'spectre like' attack vectors.
How do i become super user?
Wear your underpants on the outside and put on a cape.

User avatar
n0ctilucient
Shogun
Shogun
Posts: 329
Joined: 21 Apr 2017, 15:59
Distribution: fullmoonremix
Location: 127.0.0.1
Contact:

Retpoline?

Post#11 by n0ctilucient » 02 Mar 2018, 02:12

In the 21 century... it seems there is a sharp increase
in hardware exploits that are focused on persistance.

Once apon a time all that was needed was to pull the
mobo battery and/or switch the jumpers to kill the attack.

Now if the hardware gets infested... you have to toss it in the garbage.

This month I'm doing an Intel mITX "rack2tower "server build and in hindsight I wish I had chosen AMD instead.
:hmmm: I do NOT have the "right" to tell anyone what they should do...
but I reserve the "right" to tell them what they should "consider".

Post Reply