SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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:
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
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".
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.
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.
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/
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.
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
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.
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)
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?
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.
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)
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
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)
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
@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
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
