4:05 p.m.
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(a)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
10:32 p.m.
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,
--
Michel Alexandre Salim
profile: https://keyoxide.org/michel@michel-slm.name
10:07 a.m.
> 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.
noon
New subject: F36 Change: GNU Toolchain Update (gcc 12, glibc 2.35) (late System-Wide Change proposal)
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(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
4 p.m.
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.
--
Cheers,
Carlos.
4:56 p.m.
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
11:21 a.m.
New subject: F36 Change: GNU Toolchain Update (gcc 12, glibc 2.35) (late System-Wide Change proposal)
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
11:56 a.m.
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
4:49 a.m.
New subject: F36 Change: GNU Toolchain Update (gcc 12, glibc 2.35) (late System-Wide Change proposal)
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!
5:51 a.m.
On Sat, 22 Jan 2022 at 10:52, Andreas Schneider <asn(a)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!
https://www.debian.org/security/2008/dsa-1571
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.
5:54 a.m.
On Sat, 22 Jan 2022 at 11:51, Jonathan Wakely <jwakely(a)redhat.com> wrote:
On Sat, 22 Jan 2022 at 10:52, Andreas Schneider <asn(a)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!
>
> https://www.debian.org/security/2008/dsa-1571
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".
5:56 a.m.
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
824
days inactive
841
days old
11 comments
10 participants
participants (10)
-
Andreas Schneider -
Arjun Shankar -
Ben Cotton -
Carlos O'Donell -
Jakub Jelinek -
Jonathan Wakely -
Marek Polacek -
Mark Wielaard -
Michel Alexandre Salim -
Steve Grubb