User reports a kernel taint message following updating to kernel
5.5.5. Has anything changed in kernel 5.5 that explains this?
This is the message they're seeing:
My understanding of these messages is:
1. the proprietary nvidia driver is being loaded and used
2. since the module is not signed, the kernel is tainted
But I'm not sure what else I can infer about kernel taint. Are all the
other lockdowns still in place? Ideally the user would register a key
using mokutil, and sign the module. But if they don't do that, they
are still better off than if they disable UEFI Secure Boot to avoid
getting the kernel taint message, correct?
I built my first 5.6 custom kernel from the src.rpm yesterday in F31.
And my patch to enable the use of a daemon I run to gather entropy from
an rtl2832 (atmospheric) and put it into the kernel to keep the entropy
pool full failed. This has happened in the past, that's why I have to
patch, but the interface was never removed before. If it has been
removed, can you point me to the discussion that led to that decision.
I have to determine how secure it will be to modify random.c again in
order to continue feeding entropy to the kernel.
On another note, an observation. There seem to be pretty frequent
major revisions in the kernel PRNG generator. In some ways this is a
good thing, because it indicates that people are paying attention to it.
But it also means that past versions have been deemed unsuitable, which
decreases confidence that the current version is suitable. So, I would
be appreciative if you could also point me to the discussion
surrounding the latest major change.
Hi! TWIMC just a quick heads up for the rc3 kernel rebase in rawhide, as
I noticed a problem during my kernel vanilla builds that afaics will hit
Fedora also and can easily be missed during the update afaics:
The COPYING changed Friday night (see below), which will result in a RPM
file conflict if not worked around (sorry, German error message, but I
guess you'll get the idea):
Datei /usr/share/licenses/kernel-core/COPYING-5.6.0 aus der
mit der Datei aus dem Paket kernel-core
P.S.: Ohh, BTW: 0001-x86-Don-t-declare-__force_order-in-kaslr_64.c.patch
can be dropped, as a fix was merged upstream (that's more obvious, but I
thought I just mentioned it anyway just in case it makes somebodys life
-------- Weitergeleitete Nachricht --------
Betreff: COPYING: state that all contributions really are covered by
Datum: Fri, 21 Feb 2020 21:06:46 +0000
Antwort an: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Author: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
AuthorDate: Thu Feb 6 16:48:00 2020 +0100
Committer: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
CommitDate: Mon Feb 10 13:32:20 2020 -0800
COPYING: state that all contributions really are covered by this file
Explicitly state that all contributions to the kernel source tree
really are covered under this COPYING file in case someone thought
otherwise. Lawyers love to be pedantic, even more so than software
engineers at times, and this sentence makes them sleep easier.
Reviewed-by: Thomas Gleixner <tglx(a)linutronix.de>
Acked-by: Gustavo A. R. Silva <gustavo(a)embeddedor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
COPYING | 2 ++
1 file changed, 2 insertions(+)
diff --git a/COPYING b/COPYING
index da4cb28febe6..a635a38ef940 100644
@@ -16,3 +16,5 @@ In addition, other licenses may also apply. Please see:
for more details.
+All contributions to the Linux Kernel are subject to this COPYING file.
Hi Fedora kernel-team,
The vboxsf file-system driver for accessing folders shared by a vbox host from a (Fedora) guest
has finally been merged upstream in 5.6-rc1.
I've discussed how to move forward with this with Sergio (in the Cc)
who currently maintains a kmod for this in rpmfusion.
Sergio's preference is to switch to the in tree version ASAP.
As such I would like to backport the 5.6 patch to 5.5 and at it to
the stabilization branch, if this is ok with you ?
This will be a single patch adding a new fs/vboxsf directory
and a single new Kconfig option, the fs-driver is fully self
contained and this patch can be dropped when we switch to the 5.6
I tought that we decided to disable CONFIG_SFI a long time ago already?
This is only necessary for quite exotic and old 32 bit x86 hardware,
so we certainly should not have this enabled on x86_64. Is there any
reason why we still have this enabled ?
This is an automated email from the git hooks/post-receive script.
jforbes pushed a commit to branch master
in repository kernel-tests.
The following commit(s) were added to refs/heads/master by this push:
new 4f3679b skip paxtest for now
4f3679b is described below
Author: Justin M. Forbes <jforbes(a)fedoraproject.org>
AuthorDate: Mon Feb 10 09:05:17 2020 -0600
skip paxtest for now
default/paxtest/runtest.sh | 3 +++
1 file changed, 3 insertions(+)
diff --git a/default/paxtest/runtest.sh b/default/paxtest/runtest.sh
index 8aa3b4e..36d0ff2 100755
@@ -2,6 +2,9 @@
# Licensed under the terms of the GNU GPL License version 2
+# Skip by default for now, things need updating
To stop receiving notification emails like this one, please contact
the administrator of this repository.
I've been involved (a tiny bit) in the EFI stub cleanups which have
landed for 5.6, a such I've been building my own test kernels with
CONFIG_EFI_DISABLE_PCI_DMA=y up to know that is.
Recently I got a Lenovo X1 + Thunderbolt 3 dock for testing and
booting my own test kernel build on it failed, disabling
CONFIG_EFI_DISABLE_PCI_DMA fixes this.
Note currently we have:
[hans@x1 master]$ cat configs/fedora/generic/CONFIG_EFI_DISABLE_PCI_DMA
# CONFIG_EFI_DISABLE_PCI_DMA is not set
So the Fedora 5.6 kernels should work and this is not a bug report,
this is mostly a heads up and trying to turn my knowledge that for
now turning this on is not a good idea form private knowledge into
I will also report this upstream, so that maybe this issue can be