Re: Have the 5.6 kernels dropped support for user input of entropy to the kernel?
On Mon, 24 Feb 2020 14:40:12 -0500 Laura Abbott wrote: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/char/random.c?id=c95ea0c69ffda19381c116db2be23c7e654dac98 > > And the thread if you'd like to read > https://lore.kernel.org/linux-api/cover.1577088521.git.l...@kernel.org/ Thank you Laura! That is just what I was looking for. Though not what I was hoping for. :-) They've just decided to make the kernel robust to the situation found in server farms. So, I can patch back to what I need to feed entropy into the kernel with no security concerns. Actually, it will be more secure since the kernel in a home system uses no where near the output of the rtl2832 (~ 90 KBytes / sec). Not enough for monte carlo, but plenty for the kernel and small simulations. The kernel entropy pool is 4096 bits, 512 bytes. As they say, it probably isn't necessary because the PRNG is secure under most (all?) conditions, but this can be thought of as suspenders, just in case there *is* a back door in the cha cha algorithm. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Have the 5.6 kernels dropped support for user input of entropy to the kernel?
On 2/24/20 1:24 PM, stan wrote: On Mon, 24 Feb 2020 17:29:07 +0100 Florian Weimer wrote: * stan: 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 haven't done a complete analysis yet, the changes are pretty extensive. But the marker that the callback used to trigger the daemon has been removed. - .procname = "read_wakeup_threshold", - .data = _read_wakeup_bits, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = proc_dointvec_minmax, - .extra1 = _read_thresh, - .extra2 = _read_thresh, - }, This seems to have been replaced with hard-coded functions that read from specific sources (mouse, key strokes, hard drives, etc.) to gather system entropy. I wanted to see the rationale for the changes before I invested the time to see how it is all working together now, and how to insert my code without disrupting everything. This is a pretty critical part of the kernel (I would say vital), so I like to be sure that everything is making sense, and that it was vetted properly. I'm not an expert in this, so I could be reading it all wrong, but I want to investigate before I decide. The developer description of the changes and the reasoning behind them would be the place to start. Maybe the decision was that no one was using this interface, so it didn't make sense to keep it around (more code to rot, and threaten security). https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/char/random.c?id=c95ea0c69ffda19381c116db2be23c7e654dac98 And the thread if you'd like to read https://lore.kernel.org/linux-api/cover.1577088521.git.l...@kernel.org/ ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Have the 5.6 kernels dropped support for user input of entropy to the kernel?
On Mon, 24 Feb 2020 17:29:07 +0100 Florian Weimer wrote: > * stan: > > > 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 haven't done a complete analysis yet, the changes are pretty extensive. But the marker that the callback used to trigger the daemon has been removed. - .procname = "read_wakeup_threshold", - .data = _read_wakeup_bits, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = proc_dointvec_minmax, - .extra1 = _read_thresh, - .extra2 = _read_thresh, - }, This seems to have been replaced with hard-coded functions that read from specific sources (mouse, key strokes, hard drives, etc.) to gather system entropy. I wanted to see the rationale for the changes before I invested the time to see how it is all working together now, and how to insert my code without disrupting everything. This is a pretty critical part of the kernel (I would say vital), so I like to be sure that everything is making sense, and that it was vetted properly. I'm not an expert in this, so I could be reading it all wrong, but I want to investigate before I decide. The developer description of the changes and the reasoning behind them would be the place to start. Maybe the decision was that no one was using this interface, so it didn't make sense to keep it around (more code to rot, and threaten security). ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Have the 5.6 kernels dropped support for user input of entropy to the kernel?
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. Thanks. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Have the 5.6 kernels dropped support for user input of entropy to the kernel?
* stan: > 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. How does the removal of the interface materialize itself? Thanks, Florian ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: 5.6-rc3: changed COPYING can lead to a file conflict
On Mon, 2020-02-24 at 09:09 +0100, Thorsten Leemhuis wrote: > 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 > Installation von > kernel-core-5.6.0-0.rc3.git0.1.vanilla.knurd.1.fc33.x86_64 kollidiert > mit der Datei aus dem Paket kernel-core > > -5.6.0-0.rc2.git3.1.fc33.x86_64 > > CU, knurd Thanks for the heads-up. I've added the release field to the file which means that we won't have to deal with this problem again at the expense of users having a couple more copies of the file if using Rawhide kernels. Regards, Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
5.6-rc3: changed COPYING can lead to a file conflict
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 Installation von kernel-core-5.6.0-0.rc3.git0.1.vanilla.knurd.1.fc33.x86_64 kollidiert mit der Datei aus dem Paket kernel-core -5.6.0-0.rc2.git3.1.fc33.x86_64 CU, knurd 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 easier) Weitergeleitete Nachricht Betreff: COPYING: state that all contributions really are covered by this file Datum: Fri, 21 Feb 2020 21:06:46 + Antwort an: Greg Kroah-Hartman An: git-commits-h...@vger.kernel.org Web: https://git.kernel.org/torvalds/c/74835c7db0322b6eddf091b8b062f127b8999a0a Author: Greg Kroah-Hartman AuthorDate: Thu Feb 6 16:48:00 2020 +0100 Committer: Greg Kroah-Hartman 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 Acked-by: Gustavo A. R. Silva Link: https://lore.kernel.org/r/20200206154800.ga3754...@kroah.com Signed-off-by: Greg Kroah-Hartman --- COPYING | 2 ++ 1 file changed, 2 insertions(+) diff --git a/COPYING b/COPYING index da4cb28febe6..a635a38ef940 100644 --- a/COPYING +++ b/COPYING @@ -16,3 +16,5 @@ In addition, other licenses may also apply. Please see: Documentation/process/license-rules.rst for more details. + +All contributions to the Linux Kernel are subject to this COPYING file. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
