LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Home Forums Tutorials Articles Register
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 09-02-2018, 05:12 AM   #16
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929

Quote:
Originally Posted by Petri Kaukasoina View Post
Read again. (The right answer is the latest stable release 4.18.5)
The "right answer" according to your understanding might be latest stable release 4.18.5, which is what Linus (Torvalds) "suggested" some time ago in a TED presentation (I believe), where he expressed his concerns about the growing amount of code that is going into the kernel and the increase in the frequency of the kernel releases, just paving the way for what Greg KH is advocating now, shoving the latest stable release down everyone's throat.
But maybe you only did jump to the conclusions in that blog post and forgot to take some time to read what the important concern was kjhambrick wrote in bold.

Out of kjhambrick's list of kernels, 4.14.67 (4.14.y) matches the security (and stability) he's looking after:
Quote:
Maybe it's time I bumped my Slackware 14.2 Kernels to 4.9.y, 4.14.y or 4.19.y ... ?
It also comes with a bonus, that's the ease of maintenance, which is a quality of LTS, BTW.

____________

Generally speaking, in the link to the article kjhambrick posted, I noticed the second occasion in which Greg KH is sending warnings about "the older LTS releases that are still being maintained", particularly mentioning 4.4.y, that's the kernel Slackware is currently providing as stable, and that worried me, honestly. Up until now, all these patches mitigating the CPUs vulnerabilities have been backported to the 4.4.y branch but I never took the time to actually check if the commits for these mitigations were the same in all branches.
 
Old 09-02-2018, 07:42 AM   #17
Petri Kaukasoina
Senior Member
 
Registered: Mar 2007
Posts: 1,962

Rep: Reputation: 1574Reputation: 1574Reputation: 1574Reputation: 1574Reputation: 1574Reputation: 1574Reputation: 1574Reputation: 1574Reputation: 1574Reputation: 1574Reputation: 1574
Quote:
Originally Posted by abga View Post
Up until now, all these patches mitigating the CPUs vulnerabilities have been backported to the 4.4.y branch but I never took the time to actually check if the commits for these mitigations were the same in all branches.
No. 4.4.148, 4.14.63, and 4.18.1 were released on Aug 15. Count lines containing the word 'spectre' in ChangeLogs after that:


Code:
grep spectre ChangeLog-4.4.{148,149,150,151,152,153}|wc -l
9

grep spectre ChangeLog-4.14.{63,64,65,66,67}|wc -l 
11

grep spectre ChangeLog-4.18.{1,2,3,4,5}|wc -l
24
So, just like Greg KH tells us, the latest stable one is the most secure.
 
Old 09-02-2018, 02:40 PM   #18
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
Quote:
Originally Posted by Petri Kaukasoina View Post
No. 4.4.148, 4.14.63, and 4.18.1 were released on Aug 15. Count lines containing the word 'spectre' in ChangeLogs after that:
I wasn't considering the quantity of the changes but their quality, focusing on the consistency of the patches between kernel branches/releases, counting the changes in the most actively developed "stable" kernel branch is inadequate IMO.
Tracing all these commits, reverts and backports is a difficult endeavor that will definitely take a lot of time & effort.
Quote:
Originally Posted by Petri Kaukasoina View Post
So, just like Greg KH tells us, the latest stable one is the most secure.
Didn't tell me, nor can I get a reference where Greg KH states that the latest stable is "the most secure". Again, the only clear message I get from his blog post and the article is a warning about "the older LTS releases that are still being maintained" that are in danger of not being updated/patched properly.

But then, you always have the freedom, given you have plenty of time to spend with the updates/troubleshooting, to volunteer as a guinea pig for the "latest stable".
 
Old 09-02-2018, 02:58 PM   #19
Petri Kaukasoina
Senior Member
 
Registered: Mar 2007
Posts: 1,962

Rep: Reputation: 1574Reputation: 1574Reputation: 1574Reputation: 1574Reputation: 1574Reputation: 1574Reputation: 1574Reputation: 1574Reputation: 1574Reputation: 1574Reputation: 1574
Quote:
Originally Posted by abga View Post
Didn't tell me, nor can I get a reference where Greg KH states that the latest stable is "the most secure".
The last sentence in his blog post http://kroah.com/log/blog/2018/08/24...-should-i-use/:
Quote:
Originally Posted by Greg Kroah-Hartman
I rely on the development and latest stable releases to ensure that my machines are running the fastest and most secure releases that we know how to create at this point in time.

Last edited by Petri Kaukasoina; 09-02-2018 at 03:01 PM.
 
Old 09-02-2018, 03:09 PM   #20
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2-Multilib XDM/FVWM3
Posts: 780

Rep: Reputation: 260Reputation: 260Reputation: 260
Actually, GKH recommended the kernel release supported by your distro! For Stable, PV chose 4.4.153 (GKH schedule is Older LTS) and for -current he chose 4.14.67 (GKH schedule is Latest LTS). Please read the article in context of Slackware, not in context of I'm building my own distro release.

But at the same time.... I'd like to upgrade to 4.14.67 for stable. I'm just not sure of all the steps without experimenting.

1) Is there a thread that refers to installing the latest kernel under stable?
2) Where can one find a config for 4.14.67 or do I simply use cat /proc/config to /usr/src/4.14.67?
3) Can I simply use AlienBob's SlackWiki document for kernel upgrades but use the LTS from kernel.org instead of stables kernel line of 4.4?
4) Is the latest kernel-firmware from -current required or is it the same as stable?
5) Can one use the Kernel-generic/modules/headers/source packages at packages.slackware.com from slackware 64 /a/d/k sets instead of self building?

I'll experiment. But I was curios what others think is the right path? Cheers BrianA_MN.

Last edited by bamunds; 09-03-2018 at 10:30 AM.
 
1 members found this post helpful.
Old 09-02-2018, 03:11 PM   #21
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
Quote:
Originally Posted by Petri Kaukasoina View Post
Please note that the last paragraph you pointed at (last sentence) starts with "And as for me".

As a kernel developer he simply doesn't give a damn about any releases other than the development and latest stable.
I guess, he must be tired already with all these patches and kernel releases. Wondering when they'll ditch all the extra kernel releases and focus only on the two above.
He was still more positive with LTS releases back in February:
http://kroah.com/log/blog/2018/02/05...release-model/
 
Old 09-02-2018, 03:45 PM   #22
Petri Kaukasoina
Senior Member
 
Registered: Mar 2007
Posts: 1,962

Rep: Reputation: 1574Reputation: 1574Reputation: 1574Reputation: 1574Reputation: 1574Reputation: 1574Reputation: 1574Reputation: 1574Reputation: 1574Reputation: 1574Reputation: 1574
Quote:
Originally Posted by bamunds View Post
I'd like to upgrade to 4.14.67 for stable. I'm just not sure of all the steps without experimenting.

1) Is there a thread that refers to installing the latest kernel under stable?
2) Where can one find a config for 4.14.67 or do I simply use cat /proc/config to /usr/src/4.14.67?
3) Can I simply use AlienBob's SlackWiki document for kernel upgrades but use the LTS from kernel.org instead of stables kernel line of 4.4?
4) Is the latest kernel-firmware from -current required or is it the same as stable?
5) Can one use the Kernel-generic/modules/headers/source packages at packages.slackware.com from slackware 64 /a/d sets instead of self building?
You can use the packages from -current. If you need to install the Nvidia blob, it could be a good idea to copy the .config from -current and build yourself. You can leave firmware as is or use the one from -current.

Last edited by Petri Kaukasoina; 09-02-2018 at 03:46 PM.
 
Old 09-02-2018, 04:06 PM   #23
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
Quote:
Originally Posted by bamunds View Post
But at the same time.... I'd like to upgrade to 4.14.67 for stable. I'm just not sure of all the steps without experimenting.
1) not really, but you can follow some posts from this thread:
https://www.linuxquestions.org/quest...ml#post5827097
https://www.linuxquestions.org/quest...ml#post5827361
https://www.linuxquestions.org/quest...ml#post5828502
2) If you download the kernel sources, you'll get the .config in /usr/src/linux-4.14.67
https://mirror.de.leaseweb.net/slack...slackware64/k/
3) Don't know the Wiki, follow the posts from 1)
4) YES! (you can live with the older firmware but I wouldn't recommend it)
5) See 1)

I'd suggest to move these kernel related discussions from this "The Latest Intel Microcode Update" thread before kjhambrick will report us to the mods. It's his fault starting the kernel discussion here after all

Last edited by abga; 09-02-2018 at 04:41 PM. Reason: wrong URL
 
Old 09-02-2018, 11:33 PM   #24
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2-Multilib XDM/FVWM3
Posts: 780

Rep: Reputation: 260Reputation: 260Reputation: 260
Thank you for the links and advice. To take the process of making only one change at a time... First I'll try the kernel upgrade. After the upgrade I plan to update to 14.2's KTOWN quarterly from AlienBob, and remove multilib. That should update this desktop without going to the extreme of many updates every week under the -current schedule.

Cheers, BrianA_MN

Last edited by bamunds; 09-03-2018 at 10:38 AM.
 
Old 09-03-2018, 05:31 PM   #25
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
Now coming back to the appropriate topic of this thread, The Latest Intel Microcode Update , or at least the one more recent thread I could find.
@kjhambrick hope you don't mind.

I ran the latest spectre-meltdown-checker on the core i3 Haswell road-warrior that I have with me now and noticed that I actually don't have a mitigation in my latest microcode for one of the Spectre-NG vulnerabilities, specifically CVE-2018-3640
The only lucky Slacker I could find here on LQ (post) who has this mitigated in his microcode is magicm:
https://www.linuxquestions.org/quest...ml#post5892351

This is what I get:
Code:
* CPU microcode is known to cause stability problems:  NO  (model 0x45 family 0x6 stepping 0x1 ucode 0x24 cpuid 0x0)
* CPU microcode is the latest known available version:  UNKNOWN  (latest microcode version for your CPU model is unknown)
...
CVE-2018-3640 [rogue system register read] aka 'Variant 3a'
* CPU microcode mitigates the vulnerability:  NO 
> STATUS:  VULNERABLE  (an up-to-date CPU microcode is needed to mitigate this vulnerability)

CVE-2018-3639 [speculative store bypass] aka 'Variant 4'
* Mitigated according to the /sys interface:  YES  (Mitigation: Speculative Store Bypass disabled via prctl and seccomp)
* Kernel supports speculation store bypass:  YES  (found in /proc/self/status)
> STATUS:  NOT VULNERABLE  (Mitigation: Speculative Store Bypass disabled via prctl and seccomp)
This CVE-2018-3640 is only fixed by microcode:
https://www.intel.com/content/www/us...-sa-00115.html
https://access.redhat.com/security/cve/cve-2018-3640

And according to:
https://www.intel.com/content/dam/ww...e-guidance.pdf
Page 9 - Haswell U (Intel Core Processor i3-4005U) I have the latest microcode 0x24. This microcode came with the official BIOS and I'm also using the microcode update driver with the latest microcode pack from Intel (left it there, installed and running on every boot), reporting in dmesg 0x24.
Is anyone else experiencing this?
 
Old 09-03-2018, 05:56 PM   #26
Skaendo
Senior Member
 
Registered: Dec 2014
Location: West Texas, USA
Distribution: Slackware64-14.2
Posts: 1,445

Rep: Reputation: Disabled
Quote:
Originally Posted by abga View Post
And according to:
https://www.intel.com/content/dam/ww...e-guidance.pdf
Page 9 - Haswell U (Intel Core Processor i3-4005U) I have the latest microcode 0x24. This microcode came with the official BIOS and I'm also using the microcode update driver with the latest microcode pack from Intel (left it there, installed and running on every boot), reporting in dmesg 0x24.
Is anyone else experiencing this?
According to that doc, pre-mitigation for your CPU is 0x23, and updated is 0x24.

BUT, I'm having issues with my i3-2130 Sandy Bridge. The microcode will not even early-load for some reason. I have done it many times before, and only with this latest release has it not worked. I even went through the scary process of updating the BIOS on a HP to see if that was the issue to no avail.

However, I'm more upset that Intel just decided that, "Oh, we've done enough CPU's we don't need to do the rest." Leaving my Penryn's out in the cold.

Last edited by Skaendo; 09-03-2018 at 06:00 PM.
 
1 members found this post helpful.
Old 09-03-2018, 06:40 PM   #27
kjhambrick
Senior Member
 
Registered: Jul 2005
Location: Round Rock, TX
Distribution: Slackware64 15.0 + Multilib
Posts: 2,159

Original Poster
Rep: Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512
Quote:
Originally Posted by abga View Post
Now coming back to the appropriate topic of this thread, The Latest Intel Microcode Update , or at least the one more recent thread I could find.
@kjhambrick hope you don't mind.
Please post away abga !

I see this thread as 'it belongs to everyone' and I really enjoy reading the links you've been posting.

Quote:
I ran the latest spectre-meltdown-checker on the core i3 Haswell road-warrior that I have with me now and noticed that I actually don't have a mitigation in my latest microcode for one of the Spectre-NG vulnerabilities, specifically CVE-2018-3640
The only lucky Slacker I could find here on LQ (post) who has this mitigated in his microcode is magicm:
https://www.linuxquestions.org/quest...ml#post5892351

This is what I get:
Code:
* CPU microcode is known to cause stability problems:  NO  (model 0x45 family 0x6 stepping 0x1 ucode 0x24 cpuid 0x0)
* CPU microcode is the latest known available version:  UNKNOWN  (latest microcode version for your CPU model is unknown)
...
CVE-2018-3640 [rogue system register read] aka 'Variant 3a'
* CPU microcode mitigates the vulnerability:  NO 
> STATUS:  VULNERABLE  (an up-to-date CPU microcode is needed to mitigate this vulnerability)

CVE-2018-3639 [speculative store bypass] aka 'Variant 4'
* Mitigated according to the /sys interface:  YES  (Mitigation: Speculative Store Bypass disabled via prctl and seccomp)
* Kernel supports speculation store bypass:  YES  (found in /proc/self/status)
> STATUS:  NOT VULNERABLE  (Mitigation: Speculative Store Bypass disabled via prctl and seccomp)
This CVE-2018-3640 is only fixed by microcode:
https://www.intel.com/content/www/us...-sa-00115.html
https://access.redhat.com/security/cve/cve-2018-3640

And according to:
https://www.intel.com/content/dam/ww...e-guidance.pdf
Page 9 - Haswell U (Intel Core Processor i3-4005U) I have the latest microcode 0x24. This microcode came with the official BIOS and I'm also using the microcode update driver with the latest microcode pack from Intel (left it there, installed and running on every boot), reporting in dmesg 0x24.
Is anyone else experiencing this?
[IMO]

No but I've seen enough to realize that Intel's coverage of S&M has been spotty at best.

And worse, it feels like they're treating this first as as a Marketing Issue and 'oh yeah, there are the pesky security holes too ...'

If Intel thought that they could get away with sweeping this under the rug, I believe they would.

[/IMO]

I've got four Slackware Boxes and all but the celeron are apparently 'Not Vulnerable' according to the latest spectre-meltdown-checker.sh

The Celeron N3160 has not been fully addressed by Intel yet.

-- kjh

Last edited by kjhambrick; 09-04-2018 at 06:49 AM. Reason: oops .. fix quote
 
1 members found this post helpful.
Old 09-04-2018, 12:31 AM   #28
gegechris99
Senior Member
 
Registered: Oct 2005
Location: France
Distribution: Slackware 15.0 64bit
Posts: 1,162
Blog Entries: 5

Rep: Reputation: 394Reputation: 394Reputation: 394Reputation: 394
Quote:
Originally Posted by abga View Post
I ran the latest spectre-meltdown-checker on the core i3 Haswell road-warrior that I have with me now and noticed that I actually don't have a mitigation in my latest microcode for one of the Spectre-NG vulnerabilities, specifically CVE-2018-3640
The only lucky Slacker I could find here on LQ (post) who has this mitigated in his microcode is magicm:
...
Is anyone else experiencing this?
Microcode update worked for me on Slackware64 14.2

Quote:
Kernel is Linux 4.4.153 #1 SMP Tue Aug 28 16:08:22 CDT 2018 x86_64
CPU is Intel(R) Core(TM) i3-4100M CPU @ 2.50GHz
...
* CPU microcode is known to cause stability problems: NO (model 0x3c family 0x6 stepping 0x3 ucode 0x25 cpuid 0x306c3)
* CPU microcode is the latest known available version: YES (latest known version is 0x25 according to Intel Microcode Guidance, August 8 2018)
* CPU vulnerability to the speculative execution attack variants
* Vulnerable to Variant 1: YES
* Vulnerable to Variant 2: YES
* Vulnerable to Variant 3: YES
* Vulnerable to Variant 3a: YES
* Vulnerable to Variant 4: YES
* Vulnerable to Variant l1tf: 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: YES (1 occurrence(s) found of x86 64 bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch: NO
* Kernel has mask_nospec64 (arm64): NO
> 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
* IBRS enabled and active: YES (for kernel and firmware code)
* 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)
> STATUS: NOT VULNERABLE (Full retpoline + IBPB are mitigating the vulnerability)

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
* 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)

CVE-2018-3640 [rogue system register read] aka 'Variant 3a'
* CPU microcode mitigates the vulnerability: YES
> STATUS: NOT VULNERABLE (your CPU microcode mitigates the vulnerability)

CVE-2018-3639 [speculative store bypass] aka 'Variant 4'
* Mitigated according to the /sys interface: YES (Mitigation: Speculative Store Bypass disabled via prctl and seccomp)
* Kernel supports speculation store bypass: YES (found in /proc/self/status)
> STATUS: NOT VULNERABLE (Mitigation: Speculative Store Bypass disabled via prctl and seccomp)

CVE-2018-3615/3620/3646 [L1 terminal fault] aka 'Foreshadow & Foreshadow-NG'
* Mitigated according to the /sys interface: YES (Mitigation: Page Table Inversion)
> STATUS: NOT VULNERABLE (Mitigation: Page Table Inversion)
 
1 members found this post helpful.
Old 09-04-2018, 06:40 AM   #29
kjhambrick
Senior Member
 
Registered: Jul 2005
Location: Round Rock, TX
Distribution: Slackware64 15.0 + Multilib
Posts: 2,159

Original Poster
Rep: Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512
Quote:
Originally Posted by Petri Kaukasoina View Post
No. 4.4.148, 4.14.63, and 4.18.1 were released on Aug 15. Count lines containing the word 'spectre' in ChangeLogs after that:


Code:
grep spectre ChangeLog-4.4.{148,149,150,151,152,153}|wc -l
9

grep spectre ChangeLog-4.14.{63,64,65,66,67}|wc -l 
11

grep spectre ChangeLog-4.18.{1,2,3,4,5}|wc -l
24
So, just like Greg KH tells us, the latest stable one is the most secure.

Petri Kaukasoina --

What abga said ...

The problem to solve is what words to look for and how many times do you count each word ?

I wrote a q&d Linux ChangeLog Grepper some time ago that looks for lists of REx's in the Synopsys or the body of a Commit Block in a Linux ChangeLog file.

I call the first non-blank line of each Commit the Synopsys.

This script treats each Commit block as a unit and then it searches the block amd it either matches or it does not.

It doesn't count occurrances because I wanted to see the Synopses for the 'interesting' commits.

If you run the script without arguments, it simply lists each commit in the ChangeLog along with their Synopsys Lines.

The script will optionally append the Author to each row ( -A arg ( not posted here out of courtesy )).

The script ( I call it `.get-commit` ) is appended below my sig.

Note ... I rename the standard "ChangeLog-`uname -r` files as linux-`uname -r` to make it easier to clean out my Linux Kernel ~/dld/ directory.

Example: linux-4.4.153-ChangeLog instead of 4.4.153-ChangeLog

Warning: the output from .get-commit is arbitrarily wide !

These are some examples:
Code:
# ./.get-commit linux-4.4.153    # dump ALL commit info for Linux 4.4.153

# Title       | Search Linux ChangeLogs
# Command     | /home/dld/slackware/kjh-kernel/dld/.get-commit linux-4.4.153-ChangeLog
# Ignore Case | is OFF
# SynopsisREx | none
# Generic REx | none
# Run Date    | Tue Sep  4 06:17:56 CDT 2018
# 
# FileName                       | Commit                                   | Date                           | Synopsys
  linux-4.4.153-ChangeLog        | 577189c37a844243359afce1c3c94418259fe696 | Tue Aug 28 07:23:44 2018 +0200 | Linux 4.4.153
  linux-4.4.153-ChangeLog        | 7eaa995c75bd23b57163541c3285a2c984018b7e | Fri Jul 1 10:02:44 2016 -0400  | ovl: warn instead of error if d_type is not supported
  linux-4.4.153-ChangeLog        | 0f9a6d88cd9f3b16a86639bd652202fe27096b18 | Fri May 20 09:04:26 2016 -0400 | ovl: Do d_type check only if work dir creation was successful
  linux-4.4.153-ChangeLog        | d5e678942de33a5d8545a8b7c825eb93b57be1a9 | Mon Feb 22 09:28:34 2016 -0500 | ovl: Ensure upper filesystem supports d_type
  linux-4.4.153-ChangeLog        | f9866720724db8a163cf305fc907cdab0b38fa09 | Thu Aug 24 10:50:29 2017 -0700 | x86/mm: Fix use-after-free of ldt_struct
  linux-4.4.153-ChangeLog        | adaba23ccd7d1625942f2c27612d2b416c87e011 | Sat Aug 25 06:50:15 2018 -0700 | x86/mm/pat: Fix L1TF stable backport for CPA
Case Insensitive Search for the ( Linux Release or l1tf or spectre or speculate in the Synopsys ) or ( the string cve- anywhere in the body ) from the 4.4.145 -thru- 4.4.153 ChangeLogs

Code:
# Title       | Search Linux ChangeLogs
# Command     | /home/dld/slackware/kjh-kernel/dld/.get-commit -i -a cve- -e Linux 4.4.[0-9]* -e l1tf -e speculat -e spectre linux-4.4.145-ChangeLog linux-4.4.146-ChangeLog linux-4.4.147-ChangeLog linux-4.4.148-
# Ignore Case | is ON
# SynopsisREx | 'Linux 4.4.[0-9]*' -or- 'l1tf' -or- 'speculat' -or- 'spectre'
# Generic REx | 'cve-'
# Run Date    | Tue Sep  4 06:23:37 CDT 2018
# 
# FileName                       | Commit                                   | Date                           | Synopsys
  linux-4.4.145-ChangeLog        | ac15b2b23808ee2c3264329b035a8f0f7d7f50e6 | Sat Jul 28 07:45:05 2018 +0200 | Linux 4.4.145
  linux-4.4.146-ChangeLog        | bffa1e42b3713aa7911cc3f9a6e5a2dbbf1dc789 | Mon Aug 6 16:24:42 2018 +0200  | Linux 4.4.146
  linux-4.4.146-ChangeLog        | d856749a77546f033d9a41cc681ed3a58dba18e9 | Fri Jul 27 22:43:01 2018 +0000 | net: socket: fix potential spectre v1 gadget in socketcall
  linux-4.4.146-ChangeLog        | 8cac0ce0a8853cae7dc01256f88bc9b7e53ad3ce | Tue Jul 31 21:13:16 2018 +0000 | netlink: Fix spectre v1 gadget in netlink_create()
  linux-4.4.147-ChangeLog        | 8404ae6c8c9ff23a06cf38112e83002e1088bfe1 | Thu Aug 9 12:19:28 2018 +0200  | Linux 4.4.147
  linux-4.4.148-ChangeLog        | 30a97c1e2dc39f45d9deeeccc2733278fc285d5e | Wed Aug 15 17:42:11 2018 +0200 | Linux 4.4.148
  linux-4.4.148-ChangeLog        | 8f2adf3d2118cc0822b83a7bb43475f9149a1d26 | Sat Jul 14 21:56:13 2018 +0200 | x86/speculation/l1tf: Unbreak !__HAVE_ARCH_PFN_MODIFY_ALLOWED architectures
  linux-4.4.148-ChangeLog        | eb993211b9d7856a9ab8c487c701c84103842713 | Mon Aug 13 10:15:16 2018 -0700 | x86/speculation/l1tf: Fix up CPU feature flags
  linux-4.4.148-ChangeLog        | 6b06f36f07e2c91ad0126f17d0fc8f933c827da8 | Tue Aug 7 15:09:38 2018 -0700  | x86/mm/kmmio: Make the tracer robust against L1TF
  linux-4.4.148-ChangeLog        | 02ff2769edbce2261e981effbc3c4b98fae4faf0 | Tue Aug 7 15:09:39 2018 -0700  | x86/mm/pat: Make set_memory_np() L1TF safe
  linux-4.4.148-ChangeLog        | 9feecdb6cb73feaa55b0135aee8777eaac848c78 | Tue Aug 7 15:09:37 2018 -0700  | x86/speculation/l1tf: Make pmd/pud_mknotpresent() invert
  linux-4.4.148-ChangeLog        | 0aae5fe8413dfcd949d0df1c7d6b835efecd5b3b | Tue Aug 7 15:09:36 2018 -0700  | x86/speculation/l1tf: Invert all not present mappings
  linux-4.4.148-ChangeLog        | 09049f022a9b96b0d09d90023d4f0a097a61a767 | Wed Jun 27 17:46:50 2018 +0200 | x86/speculation/l1tf: Fix up pte->pfn conversion for PAE
  linux-4.4.148-ChangeLog        | b55b06bd3b3c977da2c938d1a73d38674cb88086 | Fri Jun 22 17:39:33 2018 +0200 | x86/speculation/l1tf: Protect PAE swap entries against L1TF
  linux-4.4.148-ChangeLog        | df7fd6ccb358bd4aa3abc8a6ff995b1f3da1b0fb | Thu Jun 21 12:36:29 2018 +0200 | x86/speculation/l1tf: Extend 64bit swap file size limit
  linux-4.4.148-ChangeLog        | fa86c208d22d8179ef3d295f6084fc87390c8366 | Wed Jun 20 16:42:57 2018 -0400 | x86/bugs: Move the l1tf function and define pr_fmt properly
  linux-4.4.148-ChangeLog        | 685b44483f077c949bd5016fdfe734b662b74aba | Wed Jun 13 15:48:28 2018 -0700 | x86/speculation/l1tf: Limit swap file size to MAX_PA/2
  linux-4.4.148-ChangeLog        | d71af2dbacb5611c1dcdc16fd1d343821d61bd5e | Wed Jun 13 15:48:27 2018 -0700 | x86/speculation/l1tf: Disallow non privileged high MMIO PROT_NONE mappings
  linux-4.4.148-ChangeLog        | bf0cca01b8736a5e146a980434ba36eb036e37ac | Wed Jun 13 15:48:26 2018 -0700 | x86/speculation/l1tf: Add sysfs reporting for l1tf
  linux-4.4.148-ChangeLog        | 52dc5c9f8eee1c569974308f0bb7be64ec63565c | Wed Jun 13 15:48:25 2018 -0700 | x86/speculation/l1tf: Make sure the first page is always reserved
  linux-4.4.148-ChangeLog        | 9ee2d2da676c48a459a99f10f45c71ffca8761a8 | Wed Jun 13 15:48:24 2018 -0700 | x86/speculation/l1tf: Protect PROT_NONE PTEs against speculation
  linux-4.4.148-ChangeLog        | 9bbdab847fc9a0b8cf23fa7354e1210f0b492821 | Wed Jun 13 15:48:23 2018 -0700 | x86/speculation/l1tf: Protect swap entries against L1TF
  linux-4.4.148-ChangeLog        | 614f5e84640e382b9916b6f606328191ed0264b3 | Wed Jun 13 15:48:22 2018 -0700 | x86/speculation/l1tf: Change order of offset/type in swap entry
  linux-4.4.148-ChangeLog        | 90a231c63cc28d896ab353b027011a949e9884d3 | Wed Jun 13 15:48:21 2018 -0700 | x86/speculation/l1tf: Increase 32bit PAE __PHYSICAL_PAGE_SHIFT
  linux-4.4.148-ChangeLog        | 7744abbe29a59db367f59b0c9890356732f25a3b | Thu Jul 26 13:14:55 2018 +0200 | x86/speculation: Protect against userspace-userspace spectreRSB
  linux-4.4.148-ChangeLog        | 8dbce8a2e9cfc8e026565d75f7cb950393d04159 | Fri Aug 3 16:41:39 2018 +0200  | x86/paravirt: Fix spectre-v2 mitigations for paravirt guests
  linux-4.4.149-ChangeLog        | 45cf1802a1057650768430cf3168ff7a02163338 | Fri Aug 17 20:56:45 2018 +0200 | Linux 4.4.149
  linux-4.4.149-ChangeLog        | 17c1e0b1f6a161cc4f533d4869ff574273dbfe8d | Tue Jul 31 15:02:13 2018 -0700 | Bluetooth: hidp: buffer overflow in hidp_process_report
  linux-4.4.150-ChangeLog        | 7dc18ebc3101229d5238a2dc740804cd4836b383 | Sat Aug 18 10:45:38 2018 +0200 | Linux 4.4.150
  linux-4.4.150-ChangeLog        | 4cdedeefa38f45299b18ae692426d5baaff6b785 | Fri Aug 17 10:27:36 2018 -0700 | x86/speculation/l1tf: Exempt zeroed PTEs from inversion
  linux-4.4.151-ChangeLog        | 78f654f6cce3442937b8c7eb4b640357871363c1 | Wed Aug 22 07:48:38 2018 +0200 | Linux 4.4.151
  linux-4.4.152-ChangeLog        | 0c73169690eb1d7d6f72a128a010bd84343e503a | Fri Aug 24 13:27:02 2018 +0200 | Linux 4.4.152
  linux-4.4.152-ChangeLog        | a89f83823b97b6da1ecf7a51184b28822e78cc07 | Thu Aug 2 00:03:40 2018 -0400  | ext4: fix spectre gadget in ext4_mb_regular_allocator()
  linux-4.4.153-ChangeLog        | 577189c37a844243359afce1c3c94418259fe696 | Tue Aug 28 07:23:44 2018 +0200 | Linux 4.4.153
  linux-4.4.153-ChangeLog        | adaba23ccd7d1625942f2c27612d2b416c87e011 | Sat Aug 25 06:50:15 2018 -0700 | x86/mm/pat: Fix L1TF stable backport for CPA
A Silly Search:
Code:
# Title       | Search Linux ChangeLogs
# Command     | /home/dld/slackware/kjh-kernel/dld/.get-commit -i -e Linux 4.4.[0-9]* linux-4.4.145-ChangeLog linux-4.4.146-ChangeLog linux-4.4.147-ChangeLog linux-4.4.148-ChangeLog linux-4.4.149-ChangeLog linux-4.4.150-ChangeLog linux-4.4.151-ChangeLog linux-4.4.152-ChangeLog linux-4.4.153-ChangeLog
# Ignore Case | is ON
# SynopsisREx | 'Linux 4.4.[0-9]*'
# Generic REx | none
# Run Date    | Tue Sep  4 06:32:00 CDT 2018
# 
# FileName                       | Commit                                   | Date                           | Synopsys
  linux-4.4.145-ChangeLog        | ac15b2b23808ee2c3264329b035a8f0f7d7f50e6 | Sat Jul 28 07:45:05 2018 +0200 | Linux 4.4.145
  linux-4.4.146-ChangeLog        | bffa1e42b3713aa7911cc3f9a6e5a2dbbf1dc789 | Mon Aug 6 16:24:42 2018 +0200  | Linux 4.4.146
  linux-4.4.147-ChangeLog        | 8404ae6c8c9ff23a06cf38112e83002e1088bfe1 | Thu Aug 9 12:19:28 2018 +0200  | Linux 4.4.147
  linux-4.4.148-ChangeLog        | 30a97c1e2dc39f45d9deeeccc2733278fc285d5e | Wed Aug 15 17:42:11 2018 +0200 | Linux 4.4.148
  linux-4.4.149-ChangeLog        | 45cf1802a1057650768430cf3168ff7a02163338 | Fri Aug 17 20:56:45 2018 +0200 | Linux 4.4.149
  linux-4.4.150-ChangeLog        | 7dc18ebc3101229d5238a2dc740804cd4836b383 | Sat Aug 18 10:45:38 2018 +0200 | Linux 4.4.150
  linux-4.4.151-ChangeLog        | 78f654f6cce3442937b8c7eb4b640357871363c1 | Wed Aug 22 07:48:38 2018 +0200 | Linux 4.4.151
  linux-4.4.152-ChangeLog        | 0c73169690eb1d7d6f72a128a010bd84343e503a | Fri Aug 24 13:27:02 2018 +0200 | Linux 4.4.152
  linux-4.4.153-ChangeLog        | 577189c37a844243359afce1c3c94418259fe696 | Tue Aug 28 07:23:44 2018 +0200 | Linux 4.4.153
Anyhow ... there is probably a better way to do this, given that the ChangeLogs are generated from the Linux git repos, but I didn't find an obvious way to do what I was after,

And .get-commit may be pretty handy from time-to-time if you're playing with Kernels or if you're interested in S&M at all ...

-- kjh

This is .get-commit
Code:
#!/bin/bash

PrgNam="`basename $0`"
DirNam="`dirname  $0`"

if ! which whichone >/dev/null 2>&1
then
   alias whichone="/usr/bin/which"
fi

if [ "$DirNam" = "." ]
then
   if [ -f "$PrgNam" ]
   then
      DirNam="`pwd`"
   else
      DirNam="`whichone $PrgNam`"
      DirNam="`dirname  $DirNam`"
   fi
elif [ "$DirNam" = ".." ]
then
   DirNam="`pwd`"
   DirNam="`dirname $DirNam`"
elif [ "`dirname $DirNam`" = ".." ]
then
   FooNam="`basename $DirNam`"
   DirNam="`pwd -P`"
   DirNam="`dirname $DirNam`/$FooNam"
elif [ "$DirNam" = "" ]               # should not happen ...
then                                  # see: man 3 dirname
   DirNam="`whichone $PrgNam`"
   DirNam="`dirname  $DirNam`"
fi

AllArg="$@"
CwdDir="`pwd -P`"

DoHeader=1
DoAuthor=0
NoCase=0

SepChar=$'\034'      # bashism to set a gawk SUBSEP

SynREx=""            # look in the Synopsys for these ... or ...
SynSep=""

AnyREx=""            # look at the text for these
AnySep=""

WacExt ()
{
   echo "$@" |
   gawk '
   {
      if (( L = length( $0 )) < 1 )
      {
         print ""
         exit 0
      }
      for ( i = L ; i > 0 ; i -- )
      {
         if (( substr( $0, i,   1 ) == "." ) \
         &&  ( substr( $0, i-1, 1 ) != "/" ))
         {
            print substr( $0, 1, i-1 )
            exit 0
         }
      }
      print $0
      exit 0
   }'
   return $?
}
GetExt ()
{
   GetExtCase=""

   while [ "$1" = "-l" \
        -o "$1" = "-L" \
        -o "$1" = "-u" \
        -o "$1" = "-U" ]
   do
      if [ "$1" = "-l" -o "$1" = "-L" ]
      then
         GetExtCase="l"
         shift
      elif [ "$1" = "-u" -o "$1" = "-U" ]
      then
         GetExtCase="u"
         shift
      fi
   done

   echo "$@" |
   gawk '
   BEGIN {

      Case = "'"$GetExtCase"'" ""

   }
   function FixCase( DoCase, InStr )
   {
      if ( DoCase == "l" )
      {
         return( tolower( InStr ))
      }
      if ( DoCase == "u" )
      {
         return( toupper( InStr ))
      }
      return( InStr )
   }
   # main
   {
      if (( L = length( $0 )) < 1 )
      {
         print ""
         exit 0
      }
      for ( i = L ; i > 0 ; i -- )
      {
         if (( substr( $0, i,   1 ) == "." ) \
         &&  ( substr( $0, i-1, 1 ) != "/" ))
         {
            print FixCase( Case, substr( $0, i ))
            exit 0
         }
      }
      print ""
      exit 0
   }'
   return $?
}
Usage ()
{
   ErrNum=$1
   shift

   [ $# -gt 0 ] && echo -e "\n$*" >&2

   echo -e "\nusage:  $PrgNam [ options ] " >&2
   cat  <<Usage_EOF >&2

$PrgNam searches Linux ChangeLog Commit Synopsys for one-or-more REx

   note:  SepChar is gawk SUBSEP ( aka \\034 )

   Options:

      e)    SynREx="\${SynREx}\${SynSep}\${OPTARG}"
            SynSep="\$SepChar"
            ;;
      a)    AnyREx="\${AnyREx}\${AnySep}\${OPTARG}"
            AnySep="\$SepChar"
            ;;
      H)    DoHeader=0
            ;;
      A)    DoAuthor=1
            ;;
      i)    NoCase=1
            ;;
      h)    Usage 0
            ;;
 
Usage_EOF
 
   exit $ErrNum

}
while  getopts iAHha:e: junk 2>/dev/null
do
   case $junk in
      e)    SynREx="${SynREx}${SynSep}${OPTARG}"
            SynSep="$SepChar"
            ;;
      a)    AnyREx="${AnyREx}${AnySep}${OPTARG}"
            AnySep="$SepChar"
            ;;
      A)    DoAuthor=1
            ;;
      i)    NoCase=1
            ;;
      H)    DoHeader=0
            ;;
      h)    Usage 0
            ;;
      *)    Usage 1
            ;;
   esac
done

shift `expr $OPTIND - 1`

# echo -e "$SepChar\c"
# exit 0

gawk '
BEGIN {

   PrgNam   = "'"$PrgNam"'"   ""
   DirNam   = "'"$DirNam"'"   ""
   AllArg   = "'"$AllArg"'"   ""

   SynREx   = "'"$SynREx"'"   ""
   AnyREx   = "'"$AnyREx"'"   ""

   DoHeader = "'"$DoHeader"'" +0
   DoAuthor = "'"$DoAuthor"'" +0
   NoCase   = "'"$NoCase"'"   +0

   # a gawkism for case-insensitive Regex

   if ( NoCase == 1 ) IGNORECASE = 1

   delete SynRExAry
   NumSynREx = ParseREx( SynREx, SynRExAry )

   delete AnyRExAry
   NumAnyREx = ParseREx( AnyREx, AnyRExAry )

   DoGrep = (( NumSynREx > 0 ) || ( NumAnyREx > 0 )) ? 1 : 0

   # a commit looks like this:
   #
   # ....|....1....|....2....|....3....|....4....|....5....|....6
   # commit ac15b2b23808ee2c3264329b035a8f0f7d7f50e6
   # Author: Greg Kroah-Hartman <greg@example.com>
   # Date:   Sat Jul 28 07:45:05 2018 +0200
   # 
   #     Linux 4.4.145
   # 
   OnOffAry[ 0 ] = "OFF"
   OnOffAry[ 1 ] = "ON"

   SQ = sprintf( "%c", 39 )  # Single Quote
   DQ = sprintf( "%c", 34 )  # Double Quote

   Q0 = ""                   # outer delim
   Q2 = " | "                # inner delim

   HFmt = "# "
   HFmt = HFmt "%s%-30s"     # Q0 FileName
   HFmt = HFmt "%s%-40s"     # Q2 Commit
   HFmt = HFmt "%s%-30s"     # Q2 Date

   DFmt = ( DoHeader == 1 ) ? "  " : ""

   DFmt = DFmt "%s%-30s"     # Q0 FileName
   DFmt = DFmt "%s%-40s"     # Q2 Commit
   DFmt = DFmt "%s%-30s"     # Q2 Date

   if ( DoAuthor == 1 )
   {
      HFmt = HFmt "%s%s"     # Q2 Author
      DFmt = DFmt "%s%s"     # Q2 Author
   }
   HFmt = HFmt "%s%s"        # Q2 Synopsys
   HFmt = HFmt "%s\n"        # Q0 EoL

   DFmt = DFmt "%s%s"        # Q2 Synopsys
   DFmt = DFmt "%s\n"        # Q0 EoL

   delete LineAry
   NumLine = 0

   HeadOut  = GotSynop = 0
   FileName = Commit = Author = Date = Synopsys = ""
}
function ParseREx( InREx, OutAry,    NumREx, N, FooAry, i, FooStr )
{
   NumREx = 0
   
   # this should not happen ...

   if (( N = split( InREx, FooAry, SUBSEP )) < 1 )
   {
      return( 0 ) 
   }
   for ( i = 1 ; i <= N ; i ++ )
   {
      if ( Trim( FooAry[ i ] ) == "" )
      {
         continue
      }
      OutAry[ ++NumREx ] = FooAry[ i ]
   }
   return( NumREx )
}
function Trim( InStr )
{
   gsub ( /^[\t\n\r ]*/, "", InStr )
   gsub ( /[\t\n\r ]*$/, "", InStr )
   return ( InStr )
}
function DumpHead(   i, D, SynStr, AnyStr )
{
   if ( DoHeader == 0 )
   {
      return( 1 )
   }
   if ( NumSynREx < 1 )
   {
      SynStr = "none"
   }
   else
   {
      D = SynStr = ""

      for ( i = 1 ; i <= NumSynREx ; i ++ )
      {
         SynStr = SynStr D SQ SynRExAry[ i ] SQ
         D = " -or- "
      }
   }
   if ( NumAnyREx < 1 )
   {
      AnyStr = "none"
   }
   else
   {
      D = AnyStr = ""

      for ( i = 1 ; i <= NumAnyREx ; i ++ )
      {
         AnyStr = AnyStr D SQ AnyRExAry[ i ] SQ
         D = " -or- "
      }
   }
   print Q0 "# Title      " Q2 "Search Linux ChangeLogs" Q0
   print Q0 "# Command    " Q2 DirNam "/" PrgNam " " AllArg Q0
   print Q0 "# Ignore Case" Q2 "is " OnOffAry[ NoCase ]
   print Q0 "# SynopsisREx" Q2 SynStr Q0
   print Q0 "# Generic REx" Q2 AnyStr Q0
   print Q0 "# Run Date   " Q2 strftime( ) Q0
   print Q0 "# " Q0

   if ( DoAuthor != 1 )
   {
      printf( HFmt, Q0, "FileName"  \
                  , Q2, "Commit"    \
                  , Q2, "Date"      \
                  , Q2, "Synopsys"  \
                  , Q0  )
   }
   else
   {
      printf( HFmt, Q0, "FileName"  \
                  , Q2, "Commit"    \
                  , Q2, "Date"      \
                  , Q2, "Author"    \
                  , Q2, "Synopsys"  \
                  , Q0  )
   }
   return( 1 )
}
function ClearCommit( )
{
   delete LineAry              # GLOBAL
   NumLine = 0                 # GLOBAL

   if ( FileName != FILENAME )
   {
      FileName = FILENAME      # GLOBAL
   }
   GotSynop =  0               # GLOBAL
   Synopsys = ""               # GLOBAL

   return
}
function GrepCommit(    i, j )
{
   # no REx matches all strings

   if (( NumSynREx == 0 ) && ( NumAnyREx == 0 ))
   {
      return( 1 )
   }

   # prioritize SynREx over AnyREx
   # todo:  make a REx String for SynRExAry ...

   if ( NumSynREx > 0 )
   {
      for ( i = 1 ; i <= NumSynREx ; i ++ )
      {
         if ( match( Synopsys, SynRExAry[ i ] ))
         {
            return( 1 )
         }
      }
   }
   
   # todo:  make a REx String for AnyRExAry ...

   if (( NumAnyREx > 0 ) && ( NumLine > 0 ))
   {
      for ( i = 1 ; i <= NumAnyREx ; i ++ )
      {
         for ( j = 1 ; j <= NumLine ; j ++ )
         {
            if ( match( LineAry[ j ], AnyRExAry[ i ] ))
            {
               return( 1 )
            }
         }
      }
   }
}
function DumpCommit( ThisCommit,  NumMatch )
{
   if ( NumLine > 0 )
   {
      if ( GrepCommit( ) == 0 )
      {
         ClearCommit( )

         return( ThisCommit )
      }
      if ( HeadOut == 0 )
      {
         HeadOut = DumpHead( )
      }
      if ( DoAuthor != 1 )
      {
         printf( DFmt, Q0, FileName   \
                     , Q2, Commit     \
                     , Q2, Date       \
                     , Q2, Synopsys   \
                     , Q0  )
      }
      else
      {
         printf( DFmt, Q0, FileName   \
                     , Q2, Commit     \
                     , Q2, Date       \
                     , Q2, Author     \
                     , Q2, Synopsys   \
                     , Q0  )
      }
   }
   ClearCommit( )

   return( ThisCommit )
}
# main
{
   # these three ( commit, Author: and Date: ) are header lines

   if ( match( $0, /^commit / ))
   {
      ThisCommit = Trim( substr( $0, RSTART + RLENGTH ))

      Commit = DumpCommit( ThisCommit )
      next
   }
   if ( match( $0, /^Author: / ))
   {
      Author = Trim( substr( $0, RSTART + RLENGTH ))
      next
   }
   if ( match( $0, /^Date: / ))
   {
      Date = Trim( substr( $0, RSTART + RLENGTH ))
      next
   }
   #
   # if not a header than it is a detail ...
   #
   LineAry[ ++NumLine ] = Line = Trim( $0 )
   #
   # and the first non-blank line is the Synopsys Line
   # 
   if (( GotSynop == 0 ) && ( Line != "" ))
   {
      GotSynop = 1
      Synopsys = Line
   }
}
END {

   DumpCommit( "" )

}' $@

Last edited by kjhambrick; 09-04-2018 at 06:48 AM. Reason: remove email addr
 
2 members found this post helpful.
Old 09-04-2018, 07:48 AM   #30
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
Related to microcode update and CVE-2018-3640

@Skaendo
Thanks for the feedback. I don't know why you cannot load the latest microcode, do you get some error message in dmesg? Maybe that would help to pinpoint the cause. As for my issue, yes I have the latest microcode for my Haswell U CPU, as mentioned, it came with the BIOS from the vendor (that I flashed) before Intel released the updated microcode package for Linux.

@kjhambrick
Well, Intel did what it was the best for them technically and business-wise (their management/strategy team) given the finger pointing (competition) and Linus' rant back in January/February after they released their first microcode mitigation (reverted afterwards). They just adapted, let the "smarta$$es" also called "partners" resolve some of their issues (kernel devs & google) and continued enjoying the sales of flawed CPUs, the same as others did (AMD/ARM). It's only with the upcoming architectures they'll start to do some HW patchwork:
https://www.anandtech.com/show/13239...f-cascade-lake
https://www.anandtech.com/show/13301...and-amber-lake
And you should be naive to believe that a refund/compensation/replacement would have been even possible, at least for the CPUs still under warranty, get real

@gegechris99
Thanks for the output, your firmware is recognized by the script. Interesting.

____
Some conclusions, based on the feedback and on re-reading Intel's paper related to CVE-2018-3639 & CVE-2018-3640
https://www.intel.com/content/www/us...-sa-00115.html
- it says that the microcode that is mitigating CVE-2018-3639 will also mitigate CVE-2018-3640 (Recommendations)
- I do have the latest microcode (came with the latest BIOS) and CVE-2018-3639 is mitigated properly
- either the spectre-meltdown-checker is not doing proper work on my system (most likely as it didn't recognize the microcode), DELL have messed up the microcode in the BIOS (unlikely) or my Haswell-U CPU has a simplified speculative execution mechanism that is not affected by CVE-2018-3640 (possible but still unlikely).
https://software.intel.com/security-...-register-read
https://www.intel.com/content/www/us.../overview.html

I'm gonna wait until the next microcode release, if any, and avoid doing it with the BIOS update (again, if any). Anyway, I'm fine, CVE-2018-3640 severity rating is only Medium , case closed.

Last edited by abga; 09-04-2018 at 07:50 AM. Reason: typo
 
  


Reply



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
Updated to the latest Intel microcode, but still vulnerable to one variant. john2x Slackware 21 08-09-2018 05:38 PM
Apply new Intel microcode- no microcode.dat file Naks110 Linux - Kernel 2 06-12-2018 05:20 PM
LXer: Intel's Microcode Update for Spectre Makes a Comeback in Ubuntu's Repositories LXer Syndicated Linux News 0 04-02-2018 05:33 AM
[SOLVED] Is it possible to update intel microcode using kernel-huge and grub2, without initrd? lagavulin16 Slackware 5 01-03-2018 09:27 AM

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

All times are GMT -5. The time now is 01:56 PM.

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
Open Source Consulting | Domain Registration