F36 Change: GNU Toolchain Update (gcc 12, glibc 2.35) (late System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/GNUToolchainF36
== Summary == Update the Fedora 36 GNU Toolchain to gcc 12 and glibc 2.35.
The gcc 12 is currently under development and will be included in Fedora 36 upon release. The glibc 2.35 change will be tracked in this top-level GNU Toolchain system-wide update.
== Owner == * Name: [[User:submachine| Arjun Shankar]] * Email: arjun@redhat.com
== Detailed Description == The GNU Compiler Collection, GNU C Library, GNU Debugger, and GNU Binary Utilities make up the core part of the GNU Toolchain and it is useful for our users to transition these components as a complete implementation when making a new release of Fedora.
The GNU Compiler Collection is expected to release version 12 in Q2, before the Fedora 36 release. It will contain many new features, documented here: https://gcc.gnu.org/gcc-12/changes.html. The latest point release for gcc 12 will be included in Fedora 36, this will most probably be 12.1.
The GNU C Library version 2.35 is expected to be released in the beginning of February 2022; we have started closely tracking the glibc 2.35 development code in Fedora Rawhide and are addressing any issues as they arise. Given the present schedule Fedora 36 will branch after the release of glibc 2.35. However, the mass rebuild schedule means Fedora 36 will mass rebuild (if required) before the final release of glibc 2.35, but after the ABI is frozen.
The GNU Binutils version 2.37 and GNU Debugger version 11.1 currently included in Fedora 35 will continue to be included in Fedora 36. There will be a GNU Binutils version 2.38 released at the end of January, but the inclusion will be scheduled for Fedora 37.
== Benefit to Fedora == Stays up to date with latest features, improvements, security and bug fixes from gcc, glibc, binutils, and gdb upstream.
The goal is to track and transition to the latest components of the GNU Toolchain.
== Scope == * Proposal owners: Fedora Toolchain Team (gcc, glibc, binutils, gdb, ...) developers need to ensure that gcc, glibc, binutils, and gdb in rawhide are stable and ready for the Fedora 36 branch. * Other developers: Given that glibc is backwards compatible and we have been testing the new glibc in rawhide it should make very little impact when updated, except for the occasional deprecation warnings and removal of legacy interfaces from public header files. An update to GCC 12.1 would mean a new major release and could have broad scope for change.
* Release engineering: A mass rebuild is strongly encouraged; [https://pagure.io/releng/issue/10515]
* Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A
== Upgrade/compatibility impact == The compiler, the static linker and the the library are backwards compatible with the previous version of Fedora.
The upgrade to glibc-2.35 coincides with the [[Changes/RemoveNSCD|removal of nscd]].
Some source changes may be required for gcc 12 rebase: https://gcc.gnu.org/gcc-12/changes.html
== How To Test == The GNU Compiler Collection has its own testsuite which is run during the package build and examined by the gcc developers before being uploaded.
The GNU C Library has its own testsuite, which is run during the package build and examined by the glibc developers before being uploaded. This test suite has over 6200 tests that run to verify the correct operation of the library. In the future we may also run the microbenchmark to look for performance regressions.
== User Experience == Users will see improved performance, many bugfixes and improvements to POSIX compliance, Unicode 14 support, C.UTF-8 locale support, improved experimental support for C++20 and C++23, new compiler warnings and improvements to existing ones, and more.
== Dependencies == <!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this change depends? In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel change)? --> All packages do not need to be rebuilt due to backwards compatibility. However, it is advantageous if a mass rebuild is performed during the Fedora 36 cycle. The mass rebuild would ensure all packages can be built with the newer compiler and core runtime.
== Contingency Plan == * Contingency mechanism glibc: If glibc 2.35 proves too disruptive to compiling the distribution we could revert to 2.34, but given that Rawhide has started tracking glibc 2.35, no show-stopper problems are expected. At this point, we can still revert to upstream version 2.34 if insurmountable problems appear, but to do so may require a mass rebuild to remove new symbols from the ABI/API. * Contingency mechanism for gcc: If gcc 12 proves too disruptive to compiling the distribution we could revert to gcc 11. * Contingency deadline: Fedora mass rebuild on 2022-01-19. * Blocks release? Yes, upgrading to the gcc 12 release blocks the release. Yes, upgrading to glibc 2.35 does block the release.
== Documentation == The gcc manual contains the documentation for the release and doesn't need any more additional work.
The glibc manual contains the documentation for the release and doesn't need any more additional work.
== Release Notes == The GNU Compiler Collection version 12 is soon to be released. See https://gcc.gnu.org/gcc-12/changes.html.
The GNU C Library version 2.35 will be released at the beginning of August 2021. The current NEWS notes can be seen here as they are added: https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD
On Wed, Jan 05, 2022 at 05:05:26PM -0500, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/GNUToolchainF36
== Summary == Update the Fedora 36 GNU Toolchain to gcc 12 and glibc 2.35.
The gcc 12 is currently under development and will be included in Fedora 36 upon release. The glibc 2.35 change will be tracked in this top-level GNU Toolchain system-wide update.
...
The GNU Binutils version 2.37 and GNU Debugger version 11.1 currently included in Fedora 35 will continue to be included in Fedora 36. There will be a GNU Binutils version 2.38 released at the end of January, but the inclusion will be scheduled for Fedora 37.
What's the rationale behind holding these two back?
Best regards,
The GNU Binutils version 2.37 and GNU Debugger version 11.1 currently included in Fedora 35 will continue to be included in Fedora 36. There will be a GNU Binutils version 2.38 released at the end of January, but the inclusion will be scheduled for Fedora 37.
What's the rationale behind holding these two back?
For GDB: gdb-11.2 is in the works but isn't here yet.
For Binutils: the release of binutils-2.38 is around the corner but isn't expected to be in time for inclusion before the upcoming mass-rebuild (18th January). Even if it is released in time for the mass rebuild, that still doesn't leave enough time to include it in Rawhide and feel confident that we won't run into issues during the mass rebuild and end up blocking F36 release on a binutils fix/rollback.
Hello,
On Wednesday, January 5, 2022 5:05:26 PM EST Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/GNUToolchainF36
== Summary == Update the Fedora 36 GNU Toolchain to gcc 12 and glibc 2.35.
The gcc 12 is currently under development and will be included in Fedora 36 upon release. The glibc 2.35 change will be tracked in this top-level GNU Toolchain system-wide update.
Reading through the GCC 12 changes, there is a significant new feature to GCC that would appear to be useful for security. There is a new:
-ftrivial-auto-var-init=zero
flag that initializes all stack variables to zero. Zero being a nice safe value that makes programs crash instead of being exploitable.
Are there plans to enable this flag so that all applications, but more importantly the kernel, are hardened against uninitialized stack variables? This is one of the major classes of security bugs that could potentially be eliminated during this mass rebuild.
Cheers, -Steve
== Owner ==
- Name: [[User:submachine| Arjun Shankar]]
- Email: arjun@redhat.com
== Detailed Description == The GNU Compiler Collection, GNU C Library, GNU Debugger, and GNU Binary Utilities make up the core part of the GNU Toolchain and it is useful for our users to transition these components as a complete implementation when making a new release of Fedora.
The GNU Compiler Collection is expected to release version 12 in Q2, before the Fedora 36 release. It will contain many new features, documented here: https://gcc.gnu.org/gcc-12/changes.html. The latest point release for gcc 12 will be included in Fedora 36, this will most probably be 12.1.
The GNU C Library version 2.35 is expected to be released in the beginning of February 2022; we have started closely tracking the glibc 2.35 development code in Fedora Rawhide and are addressing any issues as they arise. Given the present schedule Fedora 36 will branch after the release of glibc 2.35. However, the mass rebuild schedule means Fedora 36 will mass rebuild (if required) before the final release of glibc 2.35, but after the ABI is frozen.
The GNU Binutils version 2.37 and GNU Debugger version 11.1 currently included in Fedora 35 will continue to be included in Fedora 36. There will be a GNU Binutils version 2.38 released at the end of January, but the inclusion will be scheduled for Fedora 37.
== Benefit to Fedora == Stays up to date with latest features, improvements, security and bug fixes from gcc, glibc, binutils, and gdb upstream.
The goal is to track and transition to the latest components of the GNU Toolchain.
== Scope ==
- Proposal owners: Fedora Toolchain Team (gcc, glibc, binutils, gdb,
...) developers need to ensure that gcc, glibc, binutils, and gdb in rawhide are stable and ready for the Fedora 36 branch.
- Other developers: Given that glibc is backwards compatible and we
have been testing the new glibc in rawhide it should make very little impact when updated, except for the occasional deprecation warnings and removal of legacy interfaces from public header files. An update to GCC 12.1 would mean a new major release and could have broad scope for change.
- Release engineering: A mass rebuild is strongly encouraged;
[https://pagure.io/releng/issue/10515]
- Policies and guidelines: N/A (not needed for this Change)
- Trademark approval: N/A (not needed for this Change)
- Alignment with Objectives: N/A
== Upgrade/compatibility impact == The compiler, the static linker and the the library are backwards compatible with the previous version of Fedora.
The upgrade to glibc-2.35 coincides with the [[Changes/RemoveNSCD|removal of nscd]].
Some source changes may be required for gcc 12 rebase: https://gcc.gnu.org/gcc-12/changes.html
== How To Test == The GNU Compiler Collection has its own testsuite which is run during the package build and examined by the gcc developers before being uploaded.
The GNU C Library has its own testsuite, which is run during the package build and examined by the glibc developers before being uploaded. This test suite has over 6200 tests that run to verify the correct operation of the library. In the future we may also run the microbenchmark to look for performance regressions.
== User Experience == Users will see improved performance, many bugfixes and improvements to POSIX compliance, Unicode 14 support, C.UTF-8 locale support, improved experimental support for C++20 and C++23, new compiler warnings and improvements to existing ones, and more.
== Dependencies ==
<!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this change depends? In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel change)? -->
All packages do not need to be rebuilt due to backwards compatibility. However, it is advantageous if a mass rebuild is performed during the Fedora 36 cycle. The mass rebuild would ensure all packages can be built with the newer compiler and core runtime.
== Contingency Plan ==
- Contingency mechanism glibc: If glibc 2.35 proves too disruptive to
compiling the distribution we could revert to 2.34, but given that Rawhide has started tracking glibc 2.35, no show-stopper problems are expected. At this point, we can still revert to upstream version 2.34 if insurmountable problems appear, but to do so may require a mass rebuild to remove new symbols from the ABI/API.
- Contingency mechanism for gcc: If gcc 12 proves too disruptive to
compiling the distribution we could revert to gcc 11.
- Contingency deadline: Fedora mass rebuild on 2022-01-19.
- Blocks release? Yes, upgrading to the gcc 12 release blocks the
release. Yes, upgrading to glibc 2.35 does block the release.
== Documentation == The gcc manual contains the documentation for the release and doesn't need any more additional work.
The glibc manual contains the documentation for the release and doesn't need any more additional work.
== Release Notes == The GNU Compiler Collection version 12 is soon to be released. See https://gcc.gnu.org/gcc-12/changes.html.
The GNU C Library version 2.35 will be released at the beginning of August 2021. The current NEWS notes can be seen here as they are added: https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD
-- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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/devel@lists.fedoraproject.or g Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 1/11/22 13:00, Steve Grubb wrote:
Hello,
On Wednesday, January 5, 2022 5:05:26 PM EST Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/GNUToolchainF36
== Summary == Update the Fedora 36 GNU Toolchain to gcc 12 and glibc 2.35.
The gcc 12 is currently under development and will be included in Fedora 36 upon release. The glibc 2.35 change will be tracked in this top-level GNU Toolchain system-wide update.
Reading through the GCC 12 changes, there is a significant new feature to GCC that would appear to be useful for security. There is a new:
-ftrivial-auto-var-init=zero
flag that initializes all stack variables to zero. Zero being a nice safe value that makes programs crash instead of being exploitable.
Are there plans to enable this flag so that all applications, but more importantly the kernel, are hardened against uninitialized stack variables? This is one of the major classes of security bugs that could potentially be eliminated during this mass rebuild.
There are currently no plans that I am aware of that involve turning on '-ftrivial-auto-var-init=zero' in the short term for Fedora. CC'ing Jakub and Marek to comment.
It is something that should be discussed, turned on in Rawhide first, and likely via redhat-rpm-config default flags first, and then we should fix any fallout.
I'd only be comfortable if we did it early and worked through the consequences. So it could be something to discuss for F37.
On Tue, Jan 11, 2022 at 05:00:57PM -0500, Carlos O'Donell wrote:
On 1/11/22 13:00, Steve Grubb wrote:
Hello,
On Wednesday, January 5, 2022 5:05:26 PM EST Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/GNUToolchainF36
== Summary == Update the Fedora 36 GNU Toolchain to gcc 12 and glibc 2.35.
The gcc 12 is currently under development and will be included in Fedora 36 upon release. The glibc 2.35 change will be tracked in this top-level GNU Toolchain system-wide update.
Reading through the GCC 12 changes, there is a significant new feature to GCC that would appear to be useful for security. There is a new:
-ftrivial-auto-var-init=zero
flag that initializes all stack variables to zero. Zero being a nice safe value that makes programs crash instead of being exploitable.
Are there plans to enable this flag so that all applications, but more importantly the kernel, are hardened against uninitialized stack variables? This is one of the major classes of security bugs that could potentially be eliminated during this mass rebuild.
There are currently no plans that I am aware of that involve turning on '-ftrivial-auto-var-init=zero' in the short term for Fedora. CC'ing Jakub and Marek to comment.
Also not aware of any plans to always enable it.
It is something that should be discussed, turned on in Rawhide first, and likely via redhat-rpm-config default flags first, and then we should fix any fallout.
I'd only be comfortable if we did it early and worked through the consequences. So it could be something to discuss for F37.
Right. It reminds me of MALLOC_PERTURB_, but for automatic variables.
Obviously it's always important to measure its slowdown (maybe run a SPEC benchmark) / compile time / stack usage. Some of it has been done: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/562872.html but that was an early version of the patch. Still, it seems like it'd be acceptable.
It's a new feature, only present in GCC 12 (which hasn't been released as of now), so I think it needs more testing before it could be (considered to be) enabled by default.
A good thing is that it doesn't suppress the -Wuninitialized warning so you still get a chance to fix your bugs. It also comes with an attribute to keep variables uninitialized even when the options is turned on.
From what I've seen its the kernel that would most benefit from the option, and it looks like it already has support for it:
CONFIG_INIT_STACK_ALL_ZERO CONFIG_INIT_STACK_ALL_PATTERN
so maybe it's enough to enable it for the kernel. Or start there, see how it does, then add it to our hardening flags.
-- Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA
Hello,
On Thursday, January 20, 2022 5:56:04 PM EST Marek Polacek wrote:
Are there plans to enable this flag so that all applications, but more importantly the kernel, are hardened against uninitialized stack variables? This is one of the major classes of security bugs that could potentially be eliminated during this mass rebuild.
There are currently no plans that I am aware of that involve turning on '-ftrivial-auto-var-init=zero' in the short term for Fedora. CC'ing Jakub and Marek to comment.
Also not aware of any plans to always enable it.
I think we should consider it. I'll start a new thread so that the topic is clearer.
It is something that should be discussed, turned on in Rawhide first, and likely via redhat-rpm-config default flags first, and then we should fix any fallout.
I'd only be comfortable if we did it early and worked through the consequences. So it could be something to discuss for F37.
Right. It reminds me of MALLOC_PERTURB_, but for automatic variables.
Obviously it's always important to measure its slowdown (maybe run a SPEC benchmark) / compile time / stack usage. Some of it has been done: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/562872.html but that was an early version of the patch. Still, it seems like it'd be acceptable.
It's a new feature, only present in GCC 12 (which hasn't been released as of now), so I think it needs more testing before it could be (considered to be) enabled by default.
That's fine. I think F37 is a good target.
A good thing is that it doesn't suppress the -Wuninitialized warning so you still get a chance to fix your bugs. It also comes with an attribute to keep variables uninitialized even when the options is turned on.
From what I've seen its the kernel that would most benefit from the option, and it looks like it already has support for it:
CONFIG_INIT_STACK_ALL_ZERO CONFIG_INIT_STACK_ALL_PATTERN
so maybe it's enough to enable it for the kernel. Or start there, see how it does, then add it to our hardening flags.
Unless it's been reworked to also allow gcc, this was a clang only option. There are a number of distributions that use clang as the compiler for the whole project. But let's discuss this in a separate thread about this topic.
Best Regards, -Steve
Hi,
On Thu, 2022-01-20 at 17:56 -0500, Marek Polacek wrote:
On Tue, Jan 11, 2022 at 05:00:57PM -0500, Carlos O'Donell wrote:
On 1/11/22 13:00, Steve Grubb wrote:
Reading through the GCC 12 changes, there is a significant new feature to GCC that would appear to be useful for security. There is a new:
-ftrivial-auto-var-init=zero
flag that initializes all stack variables to zero. Zero being a nice safe value that makes programs crash instead of being exploitable.
Are there plans to enable this flag so that all applications, but more importantly the kernel, are hardened against uninitialized stack variables? This is one of the major classes of security bugs that could potentially be eliminated during this mass rebuild.
There are currently no plans that I am aware of that involve turning on '-ftrivial-auto-var-init=zero' in the short term for Fedora. CC'ing Jakub and Marek to comment.
Also not aware of any plans to always enable it.
It is something that should be discussed, turned on in Rawhide first, and likely via redhat-rpm-config default flags first, and then we should fix any fallout.
I'd only be comfortable if we did it early and worked through the consequences. So it could be something to discuss for F37.
Right. It reminds me of MALLOC_PERTURB_, but for automatic variables.
Obviously it's always important to measure its slowdown (maybe run a SPEC benchmark) / compile time / stack usage. Some of it has been done: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/562872.html but that was an early version of the patch. Still, it seems like it'd be acceptable.
It's a new feature, only present in GCC 12 (which hasn't been released as of now), so I think it needs more testing before it could be (considered to be) enabled by default.
A good thing is that it doesn't suppress the -Wuninitialized warning so you still get a chance to fix your bugs. It also comes with an attribute to keep variables uninitialized even when the options is turned on.
Note that it does make it impossible for valgrind memcheck to track use of uninitialized (stack) values because it will believe they have been initialized with zero in any code that is build with this flag, and it will assume that zero is a valid value.
Obviously as a valgrind hacker I am biased, believing lots of people run valgrind on production code. So I do think that makes it harder to find real security issues. Now the code will just appear to work using a possibly bogus value of zero instead of valgrind memcheck pointing out where and why you are using an uninitialized value.
Cheers,
Mark
On Tuesday, January 11, 2022 7:00:22 PM CET Steve Grubb wrote:
Hello,
On Wednesday, January 5, 2022 5:05:26 PM EST Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/GNUToolchainF36
== Summary == Update the Fedora 36 GNU Toolchain to gcc 12 and glibc 2.35.
The gcc 12 is currently under development and will be included in Fedora 36 upon release. The glibc 2.35 change will be tracked in this top-level GNU Toolchain system-wide update.
Reading through the GCC 12 changes, there is a significant new feature to GCC
that would appear to be useful for security. There is a new:
-ftrivial-auto-var-init=zero
flag that initializes all stack variables to zero. Zero being a nice safe value that makes programs crash instead of being exploitable.
Are there plans to enable this flag so that all applications, but more importantly the kernel, are hardened against uninitialized stack variables?
This is one of the major classes of security bugs that could potentially be eliminated during this mass rebuild.
I don't know if it is still the case, but OpenSSL used uninitialized stack variables on purpose! If you initialize them to zero might end up with the same disaster as Debian had some years ago!
https://www.debian.org/security/2008/dsa-1571
There be dragons!
On Sat, 22 Jan 2022 at 10:52, Andreas Schneider asn@redhat.com wrote:
On Tuesday, January 11, 2022 7:00:22 PM CET Steve Grubb wrote:
Hello,
On Wednesday, January 5, 2022 5:05:26 PM EST Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/GNUToolchainF36
== Summary == Update the Fedora 36 GNU Toolchain to gcc 12 and glibc 2.35.
The gcc 12 is currently under development and will be included in Fedora 36 upon release. The glibc 2.35 change will be tracked in this top-level GNU Toolchain system-wide update.
Reading through the GCC 12 changes, there is a significant new feature to GCC
that would appear to be useful for security. There is a new:
-ftrivial-auto-var-init=zero
flag that initializes all stack variables to zero. Zero being a nice safe value that makes programs crash instead of being exploitable.
Are there plans to enable this flag so that all applications, but more importantly the kernel, are hardened against uninitialized stack variables?
This is one of the major classes of security bugs that could potentially be eliminated during this mass rebuild.
I don't know if it is still the case, but OpenSSL used uninitialized stack variables on purpose! If you initialize them to zero might end up with the same disaster as Debian had some years ago!
IIRC it wasn't that simple. The necessary entropy was *not* coming from uninitialized bytes. There were other sources of *real* entropy, but the Debian patch caused *none* of it to be added to the pool (except for the PID). Zeroing the uninitialized bytes would *not* hurt as long as the *real* sources of entropy still get added.
On Sat, 22 Jan 2022 at 11:51, Jonathan Wakely jwakely@redhat.com wrote:
On Sat, 22 Jan 2022 at 10:52, Andreas Schneider asn@redhat.com wrote:
On Tuesday, January 11, 2022 7:00:22 PM CET Steve Grubb wrote:
Hello,
On Wednesday, January 5, 2022 5:05:26 PM EST Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/GNUToolchainF36
== Summary == Update the Fedora 36 GNU Toolchain to gcc 12 and glibc 2.35.
The gcc 12 is currently under development and will be included in Fedora 36 upon release. The glibc 2.35 change will be tracked in this top-level GNU Toolchain system-wide update.
Reading through the GCC 12 changes, there is a significant new feature to GCC
that would appear to be useful for security. There is a new:
-ftrivial-auto-var-init=zero
flag that initializes all stack variables to zero. Zero being a nice safe value that makes programs crash instead of being exploitable.
Are there plans to enable this flag so that all applications, but more importantly the kernel, are hardened against uninitialized stack variables?
This is one of the major classes of security bugs that could potentially be eliminated during this mass rebuild.
I don't know if it is still the case, but OpenSSL used uninitialized stack variables on purpose! If you initialize them to zero might end up with the same disaster as Debian had some years ago!
IIRC it wasn't that simple. The necessary entropy was *not* coming from uninitialized bytes. There were other sources of *real* entropy, but the Debian patch caused *none* of it to be added to the pool (except for the PID). Zeroing the uninitialized bytes would *not* hurt as long as the *real* sources of entropy still get added.
Also, I think the count of added entropy was still being updated even though nothing got added.
The bug was more complicated than just "an uninitialized stack buffer didn't get used as entropy".
On Sat, Jan 22, 2022 at 11:51:37AM +0000, Jonathan Wakely wrote:
IIRC it wasn't that simple. The necessary entropy was *not* coming from uninitialized bytes. There were other sources of *real* entropy, but the Debian patch caused *none* of it to be added to the pool (except for the PID). Zeroing the uninitialized bytes would *not* hurt as long as the *real* sources of entropy still get added.
And one really can't rely on entropy from uninitialized variables, using them is UB, so the compiler may already use zeros in there instead, or could have optimized those entirely etc.
Jakub
-
Andreas Schneider -
Arjun Shankar -
Ben Cotton -
Carlos O'Donell -
Jakub Jelinek -
Jonathan Wakely -
Marek Polacek -
Mark Wielaard -
Michel Alexandre Salim -
Steve Grubb