LinuxQuestions.org
Latest LQ Deal: Complete CCNA, CCNP & Red Hat Certification Training Bundle
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 03-16-2018, 08:00 AM   #136
kjhambrick
Senior Member
 
Registered: Jul 2005
Location: Round Rock, TX
Distribution: Slackware64 14.2 + Multilib
Posts: 1,426

Rep: Reputation: 832Reputation: 832Reputation: 832Reputation: 832Reputation: 832Reputation: 832Reputation: 832

Thanks for that link abga !

I read it 'way back' in January and forgot ALL about it now that it's off my LWN Front Page

It's scary ... the murky fog seems to be lifting WRT all this stuff

-- kjh

Last edited by kjhambrick; 03-16-2018 at 08:09 AM.
 
Old 03-16-2018, 08:07 AM   #137
teoberi
Member
 
Registered: Jan 2018
Location: Romania
Distribution: Slackware64-current (servers) / Ubuntu (workstations)
Posts: 56

Rep: Reputation: 13
Now I understand what "IBRS_FW" means!
https://patchwork.kernel.org/patch/10218901/
 
1 members found this post helpful.
Old 03-16-2018, 09:31 AM   #138
55020
Senior Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 1,294
Blog Entries: 4

Rep: Reputation: Disabled
Quote:
Originally Posted by teoberi View Post
If I run Spectre and Meltdown mitigation detection tool v0.35 I get:

This means that the Slackware kernel is not compiled with support for IBRS/IBPB?
RedHat recommends here
https://access.redhat.com/articles/3311301
these options

My question is how can I activate IBRS/IBPB support?
teoberi, Red Hat has its own nonstandard patches. Those options do not exist in anybody else's kernel, including Linus' kernel or the Greg K-H stable kernels. If you grep for 'ibrs_enabled' in the official source of 4.15.10, or 4.4.121, that option does not exist.

The "Skylake problem" is highly debatable. People have been quoting a kernel discussion from early January, but there have been more discussions about it since then, including in mid-January.

Slackware has the latest un-fucked-with kernels from Linus via Greg K-H. It has all the Spectre and Meltdown fixes that Linus and Greg K-H have approved (... in the case of 14.2, at the end of last month). If the kernel without Red Hat patches is good enough for Linus, and if it's good enough for Greg K-H, and Patrick, then it's good enough for me, and in my opinion you should stop worrying.

Edit: Please stop quoting that LWN link from 4th January. It's obsolete. As far as I can work out, the kernel now includes David Woodhouse's patch from 20th January to automatically configure the spectre_v2 mitigation -- see arch/x86/kernel/cpu/bugs.c:

Code:
/* Check for Skylake-like CPUs (for RSB handling) */
static bool __init is_skylake_era(void)
{
	if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
	    boot_cpu_data.x86 == 6) {
		switch (boot_cpu_data.x86_model) {
		case INTEL_FAM6_SKYLAKE_MOBILE:
		case INTEL_FAM6_SKYLAKE_DESKTOP:
		case INTEL_FAM6_SKYLAKE_X:
		case INTEL_FAM6_KABYLAKE_MOBILE:
		case INTEL_FAM6_KABYLAKE_DESKTOP:
			return true;
		}
	}
	return false;
}

[...]

retpoline_auto:
	if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
	retpoline_amd:
		if (!boot_cpu_has(X86_FEATURE_LFENCE_RDTSC)) {
			pr_err("Spectre mitigation: LFENCE not serializing, switching to generic retpoline\n");
			goto retpoline_generic;
		}
		mode = retp_compiler() ? SPECTRE_V2_RETPOLINE_AMD :
					 SPECTRE_V2_RETPOLINE_MINIMAL_AMD;
		setup_force_cpu_cap(X86_FEATURE_RETPOLINE_AMD);
		setup_force_cpu_cap(X86_FEATURE_RETPOLINE);
	} else {
	retpoline_generic:
		mode = retp_compiler() ? SPECTRE_V2_RETPOLINE_GENERIC :
					 SPECTRE_V2_RETPOLINE_MINIMAL;
		setup_force_cpu_cap(X86_FEATURE_RETPOLINE);
	}

	spectre_v2_enabled = mode;
	pr_info("%s\n", spectre_v2_strings[mode]);

	/*
	 * If neither SMEP nor PTI are available, there is a risk of
	 * hitting userspace addresses in the RSB after a context switch
	 * from a shallow call stack to a deeper one. To prevent this fill
	 * the entire RSB, even when using IBRS.
	 *
	 * Skylake era CPUs have a separate issue with *underflow* of the
	 * RSB, when they will predict 'ret' targets from the generic BTB.
	 * The proper mitigation for this is IBRS. If IBRS is not supported
	 * or deactivated in favour of retpolines the RSB fill on context
	 * switch is required.
	 */
	if ((!boot_cpu_has(X86_FEATURE_PTI) &&
	     !boot_cpu_has(X86_FEATURE_SMEP)) || is_skylake_era()) {
		setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
		pr_info("Spectre v2 mitigation: Filling RSB on context switch\n");
	}

	/* Initialize Indirect Branch Prediction Barrier if supported */
	if (boot_cpu_has(X86_FEATURE_IBPB)) {
		setup_force_cpu_cap(X86_FEATURE_USE_IBPB);
		pr_info("Spectre v2 mitigation: Enabling Indirect Branch Prediction Barrier\n");
	}

	/*
	 * Retpoline means the kernel is safe because it has no indirect
	 * branches. But firmware isn't, so use IBRS to protect that.
	 */
	if (boot_cpu_has(X86_FEATURE_IBRS)) {
		setup_force_cpu_cap(X86_FEATURE_USE_IBRS_FW);
		pr_info("Enabling Restricted Speculation for firmware calls\n");
	}

Last edited by 55020; 03-16-2018 at 09:45 AM. Reason: Can we please stop worrying and look at the facts? kthxbye
 
5 members found this post helpful.
Old 03-16-2018, 05:11 PM   #139
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 720

Rep: Reputation: 400Reputation: 400Reputation: 400Reputation: 400Reputation: 400
Quote:
Originally Posted by 55020 View Post
Edit: Please stop quoting that LWN link from 4th January. It's obsolete. As far as I can work out, the kernel now includes David Woodhouse's patch from 20th January to automatically configure the spectre_v2 mitigation -- see arch/x86/kernel/cpu/bugs.c:
Thanks for verifying that the kernel debug (debugfs is Greg KH creation BTW) patch for IBRS was only adopted by RedHat (and some others, Ubuntu included):
https://lwn.net/Articles/743019/
https://en.wikipedia.org/wiki/Debugfs

David Woodhouse's patch from 20th January (actually it looks like something from 12 Jan 2018 according to the 4.4.118 kernel changelog - kernel commits) is also available in RedHat's kernel, there is no uniqueness there, they just adopted the additional IRBS patch for manually&temporary switching off/on PTI/IBRS/IBPB, that's additional to the already available persistent - boot-time spectre_v2=off kernel boot parameter from David Woodhouse's patch.
https://cdn.kernel.org/pub/linux/ker...ngeLog-4.4.118
Switching IBRS/IBPB off might be useful ATM, due to their reported performance impact, on (isolated) systems that run verified code and need to perform very well (fast).
https://lwn.net/Articles/746551/
(Variant 2 section)

@teoberi
Quote:
My question is how can I activate IBRS/IBPB support?
You shouldn't worry about that, as 55020 described, it is already activated by the automated mitigation routines in the kernel. You can however disable them or enforce them with the spectre_v2 kernel parameter:
https://github.com/torvalds/linux/bl...parameters.txt
(look for spectre_v2= )

Just for testing/proof, if you follow the link you referenced:
https://access.redhat.com/articles/3311301
and would like to disable PTI/IBRS/IBPB with the kernel boot parameters (in lilo.conf for example): append="spectre_v2=off nopti"
Then the output of that weird "Spectre and Meltdown mitigation detection tool" script will look like this:
Code:
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface:  NO  (kernel confirms your system is vulnerable)
* 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:  YES 
  * Kernel compiled with a retpoline-aware compiler:  UNKNOWN 
> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface:  NO  (kernel confirms your system is vulnerable)
* Kernel supports Page Table Isolation (PTI):  YES 
* PTI enabled and active:  NO 
* Running as a Xen PV DomU:  NO 
> STATUS:  VULNERABLE  (PTI is needed to mitigate the vulnerability)

Last edited by abga; 03-16-2018 at 05:12 PM. Reason: typo
 
3 members found this post helpful.
Old 04-13-2018, 02:04 AM   #140
teoberi
Member
 
Registered: Jan 2018
Location: Romania
Distribution: Slackware64-current (servers) / Ubuntu (workstations)
Posts: 56

Rep: Reputation: 13
Damn, I do not understand anything!
A few days ago the script "Spectre and Meltdown mitigation detection tool" displayed everything is OK -> STATUS: NOT VULNERABLE but today I'm vulnerable again:
Quote:
Spectre and Meltdown mitigation detection tool v0.36+
Checking for vulnerabilities on current system
Kernel is Linux 4.14.33 #2 SMP Sun Apr 8 16:08:43 CDT 2018 x86_64
CPU is Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
Will use kernel image /boot/vmlinuz
Will use kconfig /proc/config.gz (decompressed)
Will use System.map file /proc/kallsyms
Kernel image is Linux version 4.14.33 (root@hive64.slackware.lan) (gcc version 7.3.0 (GCC)) #1 SMP Sun Apr 8 16:07:42 CDT 2018

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 (Intel STIBP feature bit)
* 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: NO (model 158 stepping 9 ucode 0x84 cpuid 0x906e9)
* CPU vulnerability to the three speculative execution attack 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 (Mitigation: __user pointer sanitization)
* Kernel has array_index_mask_nospec (x86): YES (1 occurrence(s) found of 64 bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch: NO
* Kernel has mask_nospec64 (arm): NO
* Checking count of LFENCE instructions following a jump in kernel... NO (only 16 jump-then-lfence instructions found, should be >= 30 (heuristic))
> STATUS: NOT VULNERABLE (Mitigation: __user pointer sanitization)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface: YES (Mitigation: Full generic retpoline, IBPB, IBRS_FW)
* Mitigation 1
* Kernel is compiled with IBRS support: YES (found IBRS_FW in sysfs)
* IBRS enabled and active: YES (for firmware code)
* Kernel is compiled with IBPB support: YES (IBPB found enabled in sysfs)
* 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)
* Local gcc is retpoline-aware: YES
> STATUS: VULNERABLE (IBRS+IBPB is needed to mitigate the vulnerability)

> How to fix: To mitigate this vulnerability, you need IBRS + IBPB, both requiring hardware support from your CPU microcode in addition to kernel support. The retpoline approach doesn't work on your CPU, as this is a Skylake+ model.

> How to fix: Both your CPU and your kernel have IBRS support, but it is currently disabled. You may enable it. Check in your distro's documentation on how to do this.

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface: YES (Mitigation: PTI)
* Kernel supports Page Table Isolation (PTI): YES (found 'CONFIG_PAGE_TABLE_ISOLATION=y')
* PTI enabled and active: YES
* Reduced performance impact of PTI: YES (CPU supports INVPCID, performance impact of PTI will be greatly reduced)
* 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
 
Old 04-13-2018, 06:36 PM   #141
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 720

Rep: Reputation: 400Reputation: 400Reputation: 400Reputation: 400Reputation: 400
Quote:
Originally Posted by teoberi View Post
Damn, I do not understand anything!
A few days ago the script "Spectre and Meltdown mitigation detection tool" displayed everything is OK -> STATUS: NOT VULNERABLE but today I'm vulnerable again:
It appears to be an extra check for skylake CPUs that was recently added in the "detection tool":
https://github.com/speed47/spectre-m...ker/issues/178
speed47 states that he/she'll try to fix it during this weekend.

If you're still using that "detection tool" script, I'd suggest to follow its issues too:
https://github.com/speed47/spectre-m...checker/issues
together with the commits:
https://github.com/speed47/spectre-m...commits/master

Last edited by abga; 04-13-2018 at 06:38 PM. Reason: wrong url
 
1 members found this post helpful.
Old 04-13-2018, 07:01 PM   #142
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2 FVWM
Posts: 545

Original Poster
Rep: Reputation: 146Reputation: 146
@teoberi. I want to remind you that this thread was about how-to install or upgrade Intel microcode. My question has been marked SOLVED for a month now. Additional posts to a SOLVED thread are usually informational to the original topic, specifically how to update microcode.

There was a separate thread for Spectre/Meltdown mitigation, which I recommend you re-post this comment on. It was started by Greg KH. Good luck. Cheers
 
Old 04-14-2018, 02:23 AM   #143
teoberi
Member
 
Registered: Jan 2018
Location: Romania
Distribution: Slackware64-current (servers) / Ubuntu (workstations)
Posts: 56

Rep: Reputation: 13
OK!
 
Old 05-04-2018, 10:15 AM   #144
Skaendo
Member
 
Registered: Dec 2014
Location: West Texas, USA
Distribution: Slackware64-14.2
Posts: 773

Rep: Reputation: Disabled
Just FYI, there is a new microcode release at downloads intel.... (20180425)

And apparently they have decided that some processors are just not worthy enough to fix. WTF.

https://newsroom.intel.com/wp-conten...e-guidance.pdf

I guess no more Intel crap for me. And as a system builder/customizer/maintainer, I will no longer recommend Intel products to anyone due to their shartty support.

Last edited by Skaendo; 05-04-2018 at 10:32 AM.
 
2 members found this post helpful.
Old 05-04-2018, 12:07 PM   #145
GazL
Senior Member
 
Registered: May 2008
Posts: 4,769
Blog Entries: 14

Rep: Reputation: Disabled
I just updated here. The microcode for my processor is still the same version as the January bundle, so no change for me.

Worth noting: there's now a 'list' file included in the intel-ucode directory that upsets iucode_tool when it tries to scan for microcode to include in the earlyfw cpio image. I had to change my build script to remove it in order to prevent the error.
 
1 members found this post helpful.
Old 05-04-2018, 08:46 PM   #146
twy
Member
 
Registered: Jun 2004
Distribution: Slackware64
Posts: 47

Rep: Reputation: Disabled
I use SlackBuild (SBo),
https://slackbuilds.org/repository/1...tel-microcode/
which depends on,
https://slackbuilds.org/repository/1...m/iucode_tool/

However, with the new intel microcode release,
microcode-20180425.tgz
the intel-microcode SBo does not work anymore. The new microcode no longer includes microcode.dat, which the SBo seems to depend on.

The microcode-update-guidance.pdf shows that my CPU now has a new microcode, so I'm eager to install it when this SBo is working again. Then, my mkinitrd loads it during early boot.
 
Old 05-04-2018, 10:34 PM   #147
Skaendo
Member
 
Registered: Dec 2014
Location: West Texas, USA
Distribution: Slackware64-14.2
Posts: 773

Rep: Reputation: Disabled
Quote:
Originally Posted by twy View Post
I use SlackBuild (SBo),
https://slackbuilds.org/repository/1...tel-microcode/
which depends on,
https://slackbuilds.org/repository/1...m/iucode_tool/

However, with the new intel microcode release,
microcode-20180425.tgz
the intel-microcode SBo does not work anymore. The new microcode no longer includes microcode.dat, which the SBo seems to depend on.

The microcode-update-guidance.pdf shows that my CPU now has a new microcode, so I'm eager to install it when this SBo is working again. Then, my mkinitrd loads it during early boot.
You might have to email the maintainer and see if they know that there is a update available and ask them to update their SlackBuild.
 
Old 05-05-2018, 03:56 AM   #148
GazL
Senior Member
 
Registered: May 2008
Posts: 4,769
Blog Entries: 14

Rep: Reputation: Disabled
Ahh, I hadn't noticed that microcode.dat had gone away: I don't use the SBo buildscript and mine doesn't use it.
 
Old 05-06-2018, 03:10 PM   #149
kjhambrick
Senior Member
 
Registered: Jul 2005
Location: Round Rock, TX
Distribution: Slackware64 14.2 + Multilib
Posts: 1,426

Rep: Reputation: 832Reputation: 832Reputation: 832Reputation: 832Reputation: 832Reputation: 832Reputation: 832
Quote:
Originally Posted by twy View Post
I use SlackBuild (SBo),
https://slackbuilds.org/repository/1...tel-microcode/
which depends on,
https://slackbuilds.org/repository/1...m/iucode_tool/

However, with the new intel microcode release,
microcode-20180425.tgz
the intel-microcode SBo does not work anymore. The new microcode no longer includes microcode.dat, which the SBo seems to depend on.

The microcode-update-guidance.pdf shows that my CPU now has a new microcode, so I'm eager to install it when this SBo is working again. Then, my mkinitrd loads it during early boot.
twy --

I've modified ( butchered ) the Original intel-microcode.SlackBuild to deal with the new Structure of the Intel Microcode.tgz file.

Attached are intel-microcode.SlackBuild.txt and intel-microcode.info.txt which can be dropped into an existing COPY of your intel-microcode SBo directory.

Rename the two files without the .txt extents ( added so I could attach to this LQ Post ).

Set the Execute Permissions on intel-microcode.SlackBuild ( chmod 755 intel-microcode.SlackBuild )

The intel-microcode.info file includes a `wget-able` $DOWNLOAD variable and the MD5SUM is from Intel's Download Site.

`wget` the new microcode-20180425.tgz into the copy of the SBo Directory where you saved the modified intel-microcode.SlackBuild and intel-microcode.info files and DO check the MD5SUM ( also in the intel-microcode.info file ).

Note that there are two additional variables in the modified SlackBuild:

Code:
   XTAG      - set XTAG if you like to differentiate your Modified SlackBuilt Packages from Natural SBo Packages

               example:  XTAG=_kjh ./intel-microcode.SlackBuild

               will create a package:  /tmp/intel-microcode-20180425-noarch-1_SBo_kjh.tgz

   DO_MY_CPU - set DO_MY_CPU=YES to create an ADDITIONAL tiny initrd cpio file as /boot/intel-ucode-mycpu.cpio

               The tiny initrd cpio file contains only the microcode for the CPU on the local box.

               example:  DO_MY_CPU=YES ./intel-microcode.SlackBuild
Note that you can combine the two variables as well:
Code:
XTAG=_twy DO_MY_CPU=YES ./intel-microcode.SlackBuild
I was not exactly sure what to do about the new intel-ucode-with-caveats/ directory but it is in the Package as /lib/firmware/intel-ucode-with-caveats/ if you want to use it.

In addition, the new Kernel Patches Directory is stored as /usr/doc/intel-microcode-20180425/linux-kernel-patches/

Finally, the intel-microcode.SlackBuild will generate a /lib/firmware/microcode.bin file ( a binary version of the formerly Intel-included ASCII Text microcode.dat file )

Anyhow, I've rebuilt and installed intel-microcode-20180425-noarch-1_SBo_kjh and rebuilt the initrd files on four boxes.

They all work fine but there were no changes to the microcode files for MY CPU's ...

HTH and Have Fun !

-- kjh
Attached Files
File Type: txt intel-microcode.SlackBuild.txt (4.9 KB, 69 views)
File Type: txt intel-microcode.info.txt (318 Bytes, 48 views)
 
8 members found this post helpful.
Old 05-09-2018, 08:10 PM   #150
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2 FVWM
Posts: 545

Original Poster
Rep: Reputation: 146Reputation: 146
Quote:
Originally Posted by kjhambrick View Post
twy --

I've modified ( butchered ) the Original intel-microcode.SlackBuild to deal with the new Structure of the Intel Microcode.tgz file.
Thank you for your attention to this and your contribution with the new slackbuild.

This worked perfectly. My Pentium D 820 is 0f-04-07 code Smithfield, which is not updated and according to Intel's direction document probably won't be updated since it isn't even listed. The current BIOS is 12/12/2006 and Intel's microcode is 4-21-2005.
Time for a new machine, I think 13 years is long enough for any one processor. Cheers

Last edited by bamunds; 05-09-2018 at 08:37 PM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Is it possible to update intel microcode using kernel-huge and grub2, without initrd? lagavulin16 Slackware 5 01-03-2018 10:27 AM
intel-microcode-20170707 kjhambrick Slackware 1 07-15-2017 09:04 AM
Lenovo Thinkpad x220 - Proprietary Driver for Microcode for Intel processor? wh33t Linux - Hardware 2 06-15-2016 12:41 PM
intel-microcode error Soapm Linux - Newbie 3 06-25-2015 02:37 AM
Intel IA32 CPU microcode...What is it Jester888 Linux - General 1 02-09-2007 12:30 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 06:31 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration