[kernel-tests] 02/02: Add informational text for secureboot and
vulnerabilities
by git repository hosting
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.
5 years, 9 months
[kernel-tests] 01/02: Add dep check for nvidia-module and change
sysfs-perms to warn
by git repository hosting
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.
5 years, 9 months
kernel or X11 bug: 2560x1440 after poweroff screen VT 1920x1080
by Reindl Harald
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)
5 years, 10 months
Kernel 4.15 rebase plans
by Laura Abbott
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
5 years, 10 months
4.14.17-300.fc27.x86_64: built with wrong GCC
by Reindl Harald
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)
5 years, 10 months
Re: Testers for LCD Panel Self Refresh on laptops with Intel graphics
wanted
by Hans de Goede
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
5 years, 10 months