kernel February 2018

kernel@lists.fedoraproject.org

14 participants
11 discussions

[kernel-tests] 02/02: Add informational text for secureboot and vulnerabilities
by git repository hosting 20 Feb '18

20 Feb '18

This is an automated email from the git hooks/post-receive script. jforbes pushed a commit to branch master in repository kernel-tests. commit dc8088ae2ffb12f8d835066ddf34668da9d3b08c Author: Justin M. Forbes <jforbes(a)fedoraproject.org> Date: Tue Feb 20 09:47:46 2018 -0600 Add informational text for secureboot and vulnerabilities --- runtests.sh | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/runtests.sh b/runtests.sh index 8820c2b..aba8fc9 100755 --- a/runtests.sh +++ b/runtests.sh @@ -190,6 +190,16 @@ else printf "Submit your results to: https://apps.fedoraproject.org/kerneltest/\n" fi +echo "The following information is not submitted with your log" +echo "it is for informational purposes only" + +if [ -f /usr/bin/pesign ]; then + echo "Checking for kernel signature:" + /usr/bin/pesign -i /boot/vmlinuz-$kver -S | grep "common name" +fi + +echo "Vulnerability status:" +grep . /sys/devices/system/cpu/vulnerabilities/* if [ "$cleanrun" == "FAIL" ]; then exit 1 -- To stop receiving notification emails like this one, please contact the administrator of this repository.

1 0

[kernel-tests] 01/02: Add dep check for nvidia-module and change sysfs-perms to warn
by git repository hosting 20 Feb '18

20 Feb '18

This is an automated email from the git hooks/post-receive script. jforbes pushed a commit to branch master in repository kernel-tests. commit c795a33179550599ca2e91fc65c7f45314334581 Author: Justin M. Forbes <jforbes(a)fedoraproject.org> Date: Tue Feb 20 09:46:56 2018 -0600 Add dep check for nvidia-module and change sysfs-perms to warn --- default/sysfs-perms/runtest.sh | 2 +- thirdparty/nvidia-module/runtest.sh | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/default/sysfs-perms/runtest.sh b/default/sysfs-perms/runtest.sh index 54c4c28..47a3eb3 100755 --- a/default/sysfs-perms/runtest.sh +++ b/default/sysfs-perms/runtest.sh @@ -7,7 +7,7 @@ COUNT=$(find /sys -type f -perm 666 | ./ignore-files.sh | wc -l) if [ "$COUNT" != "0" ]; then echo Found world-writable files in sysfs. find /sys -type f -perm 666 | ./ignore-files.sh - exit -1 + exit 4 fi exit 0 diff --git a/thirdparty/nvidia-module/runtest.sh b/thirdparty/nvidia-module/runtest.sh index b00a663..81ac578 100755 --- a/thirdparty/nvidia-module/runtest.sh +++ b/thirdparty/nvidia-module/runtest.sh @@ -12,6 +12,7 @@ fi # Ensure we have curl and kernel-devel check_dep curl check_dep kernel-devel +check_dep elfutils-libelf-devel baseurl='http://http.download.nvidia.com/XFree86/Linux-x86_64' latest=`curl $baseurl/latest.txt | cut -d ' ' -f1` -- To stop receiving notification emails like this one, please contact the administrator of this repository.

1 0

extend initramfs archive format to support xattrs
by Jon Masters 19 Feb '18

19 Feb '18

Since it came up upstream, I've added a reference in the existing BZ that was long since asking for this feature in userspace cpio: https://bugzilla.redhat.com/show_bug.cgi?id=771926 Jon. -- Computer Architect | Sent from my Fedora powered laptop

1 0

[RFC/PR] enable CONFIG_DRM_AMDGPU_SI so that Southern Island devices work with amdgpu & radv
by François Cami 16 Feb '18

16 Feb '18

Hi, Using amdgpu is mandatory for Vulkan (radv) support even for older Radeons like CIK/SI. Now that amdgpu (amdgpu_drv.c) checks for CONFIG_DRM_RADEON and CONFIG_DRM_RADEON_MODULE and does not own Southern Island devices by default, it should be safe to enable CONFIG_DRM_AMDGPU_SI. Users can switch from radeon to amdgpu with grubby as described in the pull request. Could you please review the PR at: https://src.fedoraproject.org/rpms/kernel/pull-request/5 file changed: https://src.fedoraproject.org/rpms/kernel/pull-request/5#request_diff & if at all possible merge? Thank you, François

4 3

Test 4.15.3 on Xen?
by Laura Abbott 15 Feb '18

15 Feb '18

Hi, 4.15.3 is apparently broken on Xen https://bugzilla.redhat.com/show_bug.cgi?id=1544963. If you care about Xen, I'd appreciate either figuring out how to get logs or doing a bisect. Thanks, Laura

3 4

kernel or X11 bug: 2560x1440 after poweroff screen VT 1920x1080
by Reindl Harald 11 Feb '18

11 Feb '18

should i file a bug against the kernel or X11 here? i have a new AOC 31.5" screen with 2560x1440 connectd via display port to a i7-3770 which works fine after boot and as long as i don't try to switch to a VT also continues to work as expected but wehn the screen is longer powered of and you try to switch back to VT2 (CTRL+ALT+F2) you have either the wrong resolution leading that you can't read the bottom of the VT besides unreadable font more sadly in most cases doing so Xorg freezes completly up to freeze most of the machine (webserver still reachable but even ssh login for clean reboot hangs) _______________________ /etc/X11/xorg.conf.d/02-intel.conf: Section "Device" Identifier "Videocard0" Driver "modesetting" Option "AccelMethod" "glamor" EndSection _______________________ here is 2560x1440 completly missing [ 45.896] (II) modeset(0): Supported established timings: [ 45.896] (II) modeset(0): 720x400@70Hz [ 45.896] (II) modeset(0): 640x480@60Hz [ 45.896] (II) modeset(0): 640x480@67Hz [ 45.896] (II) modeset(0): 640x480@72Hz [ 45.896] (II) modeset(0): 640x480@75Hz [ 45.896] (II) modeset(0): 800x600@56Hz [ 45.896] (II) modeset(0): 800x600@60Hz [ 45.896] (II) modeset(0): 800x600@72Hz [ 45.896] (II) modeset(0): 800x600@75Hz [ 45.896] (II) modeset(0): 832x624@75Hz [ 45.896] (II) modeset(0): 1024x768@60Hz [ 45.896] (II) modeset(0): 1024x768@70Hz [ 45.896] (II) modeset(0): 1024x768@75Hz [ 45.896] (II) modeset(0): 1280x1024@75Hz [ 45.896] (II) modeset(0): Manufacturer's mask: 0 _______________________ some lines later in Xorg.0.log it looks fine: [ 45.896] (II) modeset(0): Printing probed modes for output DP-1 [ 45.896] (II) modeset(0): Modeline "2560x1440"x60.0 241.50 2560 2608 2640 2720 1440 1443 1448 1481 +hsync +vsync (88.8 kHz eP) [ 45.896] (II) modeset(0): Modeline "2560x1440"x75.0 296.00 2560 2568 2600 2666 1440 1443 1448 1481 +hsync -vsync (111.0 kHz e) [ 45.896] (II) modeset(0): Modeline "1920x1080"x60.0 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync (67.5 kHz e) [ 45.896] (II) modeset(0): Modeline "1920x1080"x50.0 148.50 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync (56.2 kHz e) [ 45.896] (II) modeset(0): Modeline "1920x1080"x59.9 148.35 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync (67.4 kHz e) [ 45.896] (II) modeset(0): Modeline "1920x1080i"x60.0 74.25 1920 2008 2052 2200 1080 1084 1094 1125 interlace +hsync +vsync (33.8 kHz e) [ 45.896] (II) modeset(0): Modeline "1920x1080i"x50.0 74.25 1920 2448 2492 2640 1080 1084 1094 1125 interlace +hsync +vsync (28.1 kHz e) [ 45.896] (II) modeset(0): Modeline "1920x1080i"x59.9 74.18 1920 2008 2052 2200 1080 1084 1094 1125 interlace +hsync +vsync (33.7 kHz e) _______________________ and here (after power on screen) xorg.0.log.old 2560x1440 is missing [ 28980.668] (II) modeset(0): Printing probed modes for output DP-1 [ 28980.668] (II) modeset(0): Modeline "1920x1080"x60.0 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync (67.5 kHz e) [ 28980.668] (II) modeset(0): Modeline "1920x1080"x50.0 148.50 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync (56.2 kHz e) [ 28980.668] (II) modeset(0): Modeline "1920x1080"x59.9 148.35 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync (67.4 kHz e) [ 28980.668] (II) modeset(0): Modeline "1920x1080i"x60.0 74.25 1920 2008 2052 2200 1080 1084 1094 1125 interlace +hsync +vsync (33.8 kHz e) [ 28980.668] (II) modeset(0): Modeline "1920x1080i"x50.0 74.25 1920 2448 2492 2640 1080 1084 1094 1125 interlace +hsync +vsync (28.1 kHz e) [ 28980.668] (II) modeset(0): Modeline "1920x1080i"x59.9 74.18 1920 2008 2052 2200 1080 1084 1094 1125 interlace +hsync +vsync (33.7 kHz e) [ 28980.668] (II) modeset(0): Modeline "1280x1440"x59.9 156.00 1280 1376 1512 1744 1440 1443 1453 1493 -hsync +vsync (89.4 kHz e) [ 28980.668] (II) modeset(0): Modeline "1680x1050"x60.0 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync (65.3 kHz e) [ 28980.668] (II) modeset(0): Modeline "1280x1024"x75.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz e)

2 2

Kernel 4.15 rebase plans
by Laura Abbott 10 Feb '18

10 Feb '18

Hi, 4.15 was released on Sunday. Fedora will be following the same rebase procedure that we have in the past: After a few stable releases, typically 4.15.2 or 4.15.3, F27 will be rebased to 4.15 with F26 rebased shortly there after. I would expect this to happen by the end of February. Note this was a tricky kernel release because of all the Spectre/ Meltdown work but that should be settled at this point. More testing is always appreciated though. Thanks, Laura

2 4

4.14.17-300.fc27.x86_64: built with wrong GCC
by Reindl Harald 07 Feb '18

07 Feb '18

how can it be that now after GCC with retpoline support is even available for users the kernel builds suddenly using an old one? ______________________________________ 4.14.16-300.fc27.x86_64 Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation) STATUS: NOT VULNERABLE (Mitigation: Full generic retpoline) 4.14.17-300.fc27.x86_64 Kernel compiled with a retpoline-aware compiler: NO (kernel reports minimal retpoline compilation) STATUS: VULNERABLE (Vulnerable: Minimal generic ASM retpoline) ______________________________________ Spectre and Meltdown mitigation detection tool v0.33 Checking for vulnerabilities on current system Kernel is Linux 4.14.17-300.fc27.x86_64 #1 SMP Mon Feb 5 14:12:30 UTC 2018 x86_64 CPU is Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz Hardware check * Hardware support (CPU microcode) for mitigation techniques * Indirect Branch Restricted Speculation (IBRS) * SPEC_CTRL MSR is available: NO * CPU indicates IBRS capability: NO * Indirect Branch Prediction Barrier (IBPB) * PRED_CMD MSR is available: NO * CPU indicates IBPB capability: NO * Single Thread Indirect Branch Predictors (STIBP) * SPEC_CTRL MSR is available: NO * CPU indicates STIBP capability: NO * Enhanced IBRS (IBRS_ALL) * CPU indicates ARCH_CAPABILITIES MSR availability: NO * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): UNKNOWN * CPU microcode is known to cause stability problems: NO * CPU vulnerability to the three speculative execution attacks variants * Vulnerable to Variant 1: YES * Vulnerable to Variant 2: YES * Vulnerable to Variant 3: YES CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1' * Mitigated according to the /sys interface: NO (kernel confirms your system is vulnerable) > STATUS: VULNERABLE (Vulnerable) CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2' * Mitigated according to the /sys interface: NO (kernel confirms your system is vulnerable) * Mitigation 1 * Kernel is compiled with IBRS/IBPB support: NO * Currently enabled features * IBRS enabled for Kernel space: NO * IBRS enabled for User space: NO * IBPB enabled: NO * Mitigation 2 * Kernel compiled with retpoline option: YES * Kernel compiled with a retpoline-aware compiler: NO (kernel reports minimal retpoline compilation) * Retpoline enabled: YES > STATUS: VULNERABLE (Vulnerable: Minimal generic ASM retpoline) CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3' * Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active) * Kernel supports Page Table Isolation (PTI): YES * PTI enabled and active: YES * Running as a Xen PV DomU: NO > STATUS: NOT VULNERABLE (Mitigation: PTI)

2 1

Re: Testers for LCD Panel Self Refresh on laptops with Intel graphics wanted
by Hans de Goede 06 Feb '18

06 Feb '18

Hi Andrew, On 05-02-18 23:02, Andrew Lutomirski wrote: > On Thu, Feb 1, 2018 at 11:34 AM, Hans de Goede <hdegoede(a)redhat.com> wrote: >> >> Hi All, >> >> For the "Improved Laptop Battery Life" feature: >> https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife >> >> I'm working on for Fedora 28 I would like to also try and enable >> Panel Self Refresh on laptops with Intel graphics, some quick tests >> have shown this to save another 0.5W (when idle / nothing on the >> screen changes). This is currently off be default because it is >> known to cause issues on some devices. So I think we will probably >> need a white- or black-list. But first we need more data on this. >> >> If you can spare 10 minutes, please see my blogpost for how to test >> this and send me a mail with the info request in the blogpost: >> https://hansdegoede.livejournal.com/18653.html >> > > I suspect that the results may be odd. After falling into a rabbit > hole when I tried to do this test, I learned a few things about the > i915 driver's PSR support: > > - Intel doesn't currently have any working CI coverage for PSR. > > - There's an Intel person who seems to be actively trying to fix PSR. > > - PSR on 4.15 on newish hardware (at least Skylake) is completely broken. > > - There are other known bugs. > > So I'm not sure that trying to tabulate PSR functionality based on > panel type seems like it may be the wrong approach. Thank you for your poking around wrt this. Can you send me an (off-list) email with the contact info for the Intel person you are talking about, before spending more time on this I would like to touch base with him/her. Regards, Hans

1 0

Testers for LCD Panel Self Refresh on laptops with Intel graphics wanted
by Hans de Goede 02 Feb '18

02 Feb '18

Hi All, For the "Improved Laptop Battery Life" feature: https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife I'm working on for Fedora 28 I would like to also try and enable Panel Self Refresh on laptops with Intel graphics, some quick tests have shown this to save another 0.5W (when idle / nothing on the screen changes). This is currently off be default because it is known to cause issues on some devices. So I think we will probably need a white- or black-list. But first we need more data on this. If you can spare 10 minutes, please see my blogpost for how to test this and send me a mail with the info request in the blogpost: https://hansdegoede.livejournal.com/18653.html Regards, Hans

3 5

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel February 2018