debuginfo sub-packages for the kernel
by Laura Abbott
Hi,
I started playing around with having RPM automatically generate the
debuginfo subpackages per
https://fedoraproject.org/wiki/Changes/SubpackageAndSourceDebuginfo
Because the kernel is a continual source of exceptions, the existing
code doesn't handle the case where the debuginfo and file may have
different names.
The kernel modules are compressed at the install stage so foo.ko
becomes foo.ko.xz. The debuginfo is generated as foo.ko.debug.
The existing code to split debugfiles.list can't detect this so
those files end up as unpackaged. A similar problem happens with
the vmlinux for the main kernel.
Is this an issue that can reasonably be fixed or worked around to
support the debuginfo subpackages for the kernel? I want to make
sure I'm not digging myself into a hole before I spend more time
on this.
Thanks,
Laura
6 years, 3 months
Different behavior for kernel entropy in 4.13 kernel
by stan
Hi,
I compile a custom kernel locally from the Fedora src.rpm. I notice
that the most recent 4.13 kernel I compiled, 4.13.0-0.rc4.git3.1, has
different behavior for the kernel entropy pool than it used to have.
The way it used to work was that when the kernel entropy pool was kept
full, or fuller, it would bleed entropy across to the pseudo-random
generator in order to reseed it. This makes the output sequence of the
PRNG indeterminate, and thus more random, and harder to attack. It is
no longer a pseudo random number generator, except in intervals.
I notice now that there is no bleed happening. When the kernel entropy
pool gets full, if there are no calls to /dev/random, it stays full.
I don't have a hardware RNG, but I harvest entropy from a sound device,
and from an rtl2832 receiver (atmospheric). They still work, if I do
cat /dev/random | rngtest -b 10
they get fired up and run full out.
But if I do
cat /dev/urandom | rngtest -b 20000
the entropy pool just sits there, and they don't run.
The entropy pool can be looked at, as root, with
cat /proc/sys/kernel/random/entropy_avail
I reset the write_wakeup_threshold there to 3840 from its default 1792,
and lower the urandom_min_reseed_secs to 5 (I think the default is 60).
Can you explain why this was changed, or point me to a discussion of
the rationale for the change? It seems like it has implications for
system security, and on the surface seems to decrease security of the
PRNG.
Thanks.
6 years, 7 months
[PATCH] disable SWIOTLB on Power (#1480380)
by Dan Horák
All supported platforms have IOMMU, thus disable.
---
baseconfig/powerpc/CONFIG_SWIOTLB | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/baseconfig/powerpc/CONFIG_SWIOTLB b/baseconfig/powerpc/CONFIG_SWIOTLB
index 5405b65..ac62bf3 100644
--- a/baseconfig/powerpc/CONFIG_SWIOTLB
+++ b/baseconfig/powerpc/CONFIG_SWIOTLB
@@ -1 +1 @@
-CONFIG_SWIOTLB=y
+# CONFIG_SWIOTLB is not set
--
2.7.5
6 years, 7 months
Adding vboxguest and vboxsf drivers to Fedora kernel pkg
by Hans de Goede
Hi,
I've been working on cleaning up the vboxguest drivers so that they
can be added to the mainline kernel for:
https://fedoraproject.org/wiki/Changes/VirtualBox_Guest_Integration
The vboxvideo driver is already upstream, atm it is in staging
because it still needs to be ported to the new atomic-kms APIs
but otherwise it is in very good state and not really of staging
quality (I've already done a lot of cleanup reducing it from
52681 in its original form to 7275 lines in staging).
Some people have expressed concerns about my plans to _temporarily_
carry patches for the vboxguest integration in the Fedora kernel pkg.
I can understand that you are reluctant to carry patches which
need to be maintained for ever and ever, but that is not the case
here.
I've been working my ass of to get these drivers cleaned up
in time for F27, so that the _cleaned up_ version can be added
to the Fedora kernels for a kernel release or 2, see:
https://github.com/jwrdegoede/vboxguest/commits/master
for all the work I've been oing on the vboxguest driver.
As mentioned on the fedora-devel list I did not contact the kernel
team before because I first wanted to have something to show and
something better then just dropping the vbox out-of-tree drivers
into the kernel as is.
The other 2 drivers needed for vboxguest integration are the vboxguest
and vboxsf drivers.
I now have the vboxguest driver ready for upstream submission,
reducing it from 100587 lines of code in /usr/src/vboxguest-5.1.24/vboxguest
to just 6324 lines for the patch I'm going to submit upstream:
https://github.com/jwrdegoede/linux-sunxi/commit/fdfa2fe410c04b11512ce3b6...
I plan to also have the vboxsf driver ready coming Friday and to submit
both upstream then.
As you can see from the above link the vboxguest driver is not big and
is completely self contained, without needing changes anywhere else
in the kernel. The vboxsf driver is the same. As such carrying these
2 drivers as patches should cause very little work and I will maintain
them both while they are patched in and afterwards.
So I'm hereby asking the Fedora kernel-team for permission to add
these 2 drivers as patches to the Fedora kernel for a kernel-release
or 2 while I finish pushing them upstream.
Regards,
Hans
6 years, 7 months