The Latest Kernel Release.

BratPit · 01-13-2018, 06:41 AM

Kernel hacker Andrew Lutomirski basically saying pre-4.14-kernel KPTI is probably buggy as hell and you better not use it

https://news.ycombinator.com/item?id=16087736

GazL · 01-13-2018, 07:15 AM

There's also the fact that pre 4.14 kernel's don't support the PCID feature of processors that have it. PCID allegedly mitigates some of the overhead KPTI introduces.

Anyway, I long ago lost faith in running backlevel kernel branches, LTS or otherwise. The only time I do it now is if something gets broken such that I can't use the latest branch.

cwizardone · 01-14-2018, 06:43 PM

Release Candidate 8 of the latest "mainline" development kernel, version 4.15, is now available at, https://www.kernel.org/

The tarball, https://git.kernel.org/torvalds/t/linux-4.15-rc8.tar.gz

Mr. Torvalds' announcement, http://lkml.iu.edu/hypermail/linux/k...1.1/06185.html

cwizardone · 01-17-2018, 03:33 AM

Kernel updates 4.14.14, 4.9.77, 4.4.112 and 3.18.92 [EOL] are now available at, https://www.kernel.org/.

The change logs,

https://cdn.kernel.org/pub/linux/ker...ngeLog-4.14.14

https://cdn.kernel.org/pub/linux/ker...angeLog-4.9.77

https://cdn.kernel.org/pub/linux/ker...ngeLog-4.4.112

https://cdn.kernel.org/pub/linux/ker...ngeLog-3.18.92

Didier Spaier · 01-17-2018, 03:48 AM

Quote:

Originally Posted by cwizardone

https://cdn.kernel.org/pub/linux/ker...ngeLog-4.4.112

Looks like more kernel upgrades are to be forecasted for some Slackware stable versions...

GazL · 01-17-2018, 03:51 AM

4.14.14 has lots more new Spectre stuff, including new config option: CONFIG_RETPOLINE

Quote:

Compile kernel with the retpoline compiler options to guard against kernel-to-user data leaks by avoiding speculative indirect branches. Requires a compiler with -mindirect-branch=thunk-extern support for full protection. The kernel may run slower.

Without compiler support, at least indirect branches in assembler code are eliminated. Since this includes the syscall entry path, it is not entirely pointless.

Lysander666 · 01-17-2018, 03:56 AM

Quote:

Originally Posted by Didier Spaier

Looks like more kernel upgrades are to be forecasted for some Slackware stable versions...

Egad! Do you think we can expect more frequent updates until this Spectre debacle blows over? I haven't looked into the microcode yet, I don't know how necessary that is, especially since I run an Atom.

ponce · 01-17-2018, 04:00 AM

I've tested the new 4.14.14 with the tool and it looks like we are still far...

Code:

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

Checking for vulnerabilities against running kernel Linux 4.14.14-ck1 #1 SMP Wed Jan 17 10:23:13 CET 2018 x86_64
CPU is Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking whether we're safe according to the /sys interface:  NO  (kernel confirms your system is vulnerable)
> STATUS:  VULNERABLE  (Vulnerable)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Checking whether we're safe according to the /sys interface:  NO  (kernel confirms your system is vulnerable)
> STATUS:  VULNERABLE  (Vulnerable: Minimal generic ASM retpoline)

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

A false sense of security is worse than no security at all, see --disclaimer
# ./spectre-meltdown-checker.sh --kernel /boot/vmlinuz-ck --config /usr/src/linuxck/.config --map /boot/System.map-ck
Spectre and Meltdown mitigation detection tool v0.31

Checking for vulnerabilities against specified kernel

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel:  NO
> STATUS:  VULNERABLE  (only 46 opcodes found, should be >= 70, heuristic to be improved when official patches become available)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation
*     The SPEC_CTRL MSR is available:  YES
*     The SPEC_CTRL CPUID feature bit is set:  YES
*   Kernel support for IBRS:  NO
*   IBRS enabled for Kernel space:  N/A  (not testable in offline mode)
*   IBRS enabled for User space:  N/A  (not testable in offline mode)
* Mitigation 2
*   Kernel compiled with retpoline option:  YES
*   Kernel compiled with a retpoline-aware compiler:  NO
> 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'
* Kernel supports Page Table Isolation (PTI):  YES
* PTI enabled and active:  N/A  (can't verify if PTI is enabled in offline mode)
> STATUS:  NOT VULNERABLE  (offline mode: PTI will mitigate the vulnerability if enabled at runtime)

A false sense of security is worse than no security at all, see --disclaimer

GazL · 01-17-2018, 04:08 AM

Quote:

Originally Posted by Lysander666

Egad! Do you think we can expect more frequent updates until this Spectre debacle blows over? I haven't looked into the microcode yet, I don't know how necessary that is, especially since I run an Atom.

I expect Spectre will be the gift that keeps on giving for quite a while.

allend · 01-17-2018, 05:05 AM

Just a small update on the use of the 4.13 and 4.14 series kernel with my netbook with an Intel 945GME GPU, which had been giving me screen corruption after graphics mode switch during boot and then when X was started as reported in post #276. I finally came across this thread that gave me a solution.
It turns out that I had been using lilo as the boot manager using a 'vga=xxx' in /etc/lilo.conf. Changing that to 'vga = normal' eliminated the screen corruption during boot.
Might be useful to someone else.

kjhambrick · 01-17-2018, 06:39 AM

Just now booted 4.4.112 ( generic ) on my Slackware64 14.2 System.

The 4.4.112 ChangeLog lists a number of commits that apparently lay a foundation for upcoming Spectre fixes.

One thing mentioned in the ChangeLog is that I see in my /proc/cpuinfo file is that the bugs: entry is now populated ( bugs: was empty with 4.4.111 ).

Anyhow 4.4.112 booted fine and seems to run fine after building against the official Slackware64 4.4.111 .config files.

-- kjh

The bugs: entry in /proc/cpuinfo for the 4.4.111 Kernel was empty. But now with 4.4.112:

Code:

bugs  : cpu_meltdown spectre_v1 spectre_v2

Another mentionable from the ChangeLog is that a new /sys/devices/system/cpu/vulnerabilities/ directory has been added and is now populated.

Code:

# ls -lad /sys/devices/system/cpu/vulnerabilities/*

-r--r--r-- 1 root root 4096 Jan 17 06:23 /sys/devices/system/cpu/vulnerabilities/meltdown
-r--r--r-- 1 root root 4096 Jan 17 06:23 /sys/devices/system/cpu/vulnerabilities/spectre_v1
-r--r--r-- 1 root root 4096 Jan 17 06:23 /sys/devices/system/cpu/vulnerabilities/spectre_v2

What is in there ?

Code:

# for i in `find /sys/devices/system/cpu/vulnerabilities -type f -print`; do echo "##### `basename $i` #####" ; cat $i ; done

##### spectre_v1 #####
Vulnerable
##### spectre_v2 #####
Vulnerable
##### meltdown #####
Mitigation: PTI

bassmadrigal · 01-17-2018, 07:11 AM

Quote:

Originally Posted by kjhambrick

The bugs: entry in /proc/cpuinfo for the 4.4.111 Kernel was empty. But now with 4.4.112:

Code:

bugs  : cpu_meltdown spectre_v1 spectre_v2

I can't access kernel.org from work (I don't know why they have it in their filter lists), but do the changelogs mention if the bugs section will always be populated until the come out with a processor that isn't affected? Or once the system is no longer affected by those bugs, will it be removed? I imagine it is the former and will be a permanent item for any processors with those vulnerabilities, regardless of whether the OS or microcode prevents execution of the bugs.

kjhambrick · 01-17-2018, 07:23 AM

Quote:

Originally Posted by bassmadrigal

I can't access kernel.org from work (I don't know why they have it in their filter lists), but do the changelogs mention if the bugs section will always be populated until the come out with a processor that isn't affected? Or once the system is no longer affected by those bugs, will it be removed? I imagine it is the former and will be a permanent item for any processors with those vulnerabilities, regardless of whether the OS or microcode prevents execution of the bugs.

bassmadrigal --

I am by no means an expert but the commits below seem related to your Q.

They seem to say 'set the vulnerable bits' until proven that the CPU is not vulnerable which seems the most conservative route to take ...

HTH.

-- kjh

Code:

<<snip>> -----------------------------------------------------------------
commit 73492b6860129bc3b87b1730486940d0850bfb23
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sun Jan 7 22:48:00 2018 +0100

    sysfs/cpu: Add vulnerability folder
    
    commit 87590ce6e373d1a5401f6539f0c59ef92dd924a9 upstream.
    
    As the meltdown/spectre problem affects several CPU architectures, it makes
    sense to have common way to express whether a system is affected by a
    particular vulnerability or not. If affected the way to express the
    mitigation should be common as well.
    
    Create /sys/devices/system/cpu/vulnerabilities folder and files for
    meltdown, spectre_v1 and spectre_v2.
    
    Allow architectures to override the show function.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Linus Torvalds <torvalds@linuxfoundation.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Link: https://lkml.kernel.org/r/20180107214913.096657732@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

<<snip>> -----------------------------------------------------------------
commit caae411b6ee026c7f43d67932e9b5008cf623293
Author: David Woodhouse <dwmw@amazon.co.uk>
Date:   Sat Jan 6 11:49:23 2018 +0000

    x86/cpufeatures: Add X86_BUG_SPECTRE_V[12]
    
    commit 99c6fa2511d8a683e61468be91b83f85452115fa upstream.
    
    Add the bug bits for spectre v1/2 and force them unconditionally for all
    cpus.
    
    Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: gnomes@lxorguk.ukuu.org.uk
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jikos@kernel.org>
    Cc: Andy Lutomirski <luto@amacapital.net>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Kees Cook <keescook@google.com>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc: Greg Kroah-Hartman <gregkh@linux-foundation.org>
    Cc: Paul Turner <pjt@google.com>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/1515239374-23361-2-git-send-email-dwmw@amazon.co.uk
    Signed-off-by: Razvan Ghitulete <rga@amazon.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

<<snip>> -----------------------------------------------------------------
commit 07c7aa5e7e8ac83768246822b61ebffbdea61ff7
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Mon Dec 4 15:07:33 2017 +0100

    x86/cpufeatures: Add X86_BUG_CPU_INSECURE
    
    commit a89f040fa34ec9cd682aed98b8f04e3c47d998bd upstream.
    
    Many x86 CPUs leak information to user space due to missing isolation of
    user space and kernel space page tables. There are many well documented
    ways to exploit that.
    
    The upcoming software migitation of isolating the user and kernel space
    page tables needs a misfeature flag so code can be made runtime
    conditional.
    
    Add the BUG bits which indicates that the CPU is affected and add a feature
    bit which indicates that the software migitation is enabled.
    
    Assume for now that _ALL_ x86 CPUs are affected by this. Exceptions can be
    made later.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Brian Gerst <brgerst@gmail.com>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: David Laight <David.Laight@aculab.com>
    Cc: Denys Vlasenko <dvlasenk@redhat.com>
    Cc: Eduardo Valentin <eduval@amazon.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Juergen Gross <jgross@suse.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: aliguori@amazon.com
    Cc: daniel.gruss@iaik.tugraz.at
    Cc: hughd@google.com
    Cc: keescook@google.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

<<snip>> -----------------------------------------------------------------

BW-userx · 01-17-2018, 07:53 AM

so I got 4.4.111 sitting here, the whole kit boodel' source and everything, and I am wondering if anyone else has installed this update on 14.2 stable without incident?

Lysander666 · 01-17-2018, 08:09 AM

Quote:

Originally Posted by BW-userx

so I got 4.4.111 sitting here, the whole kit boodel' source and everything, and I am wondering if anyone else has installed this update on 14.2 stable without incident?

I put it through yesterday, my first kernel upgrade in Slack, no problem at all. Well, I had some leftover 4.4.88 packages afterwards but that's my fault since I only downloaded the smp packages for 4.4.111. Made an initrd, switched to generic, ran lilo. A few more comments here:

https://www.linuxquestions.org/quest...un-4175621733/