siddhesh wrote:
> [...] The ideal would be a rawhide-debug (or f37-build-debug,
> etc) target that disables trivial-auto-var-init and maybe also some
> other flags to improve debuggability, but that could be a separate
> proposal.
We don't build "debug" variants of the distro RPMs for a
On Mon, May 16, 2022 at 7:18 PM Mark Wielaard wrote:
>
> Hi Steve,
>
> On Wed, 2022-05-11 at 22:35 -0400, Steve Grubb wrote:
> > On Monday, May 9, 2022 5:10:07 AM EDT Daniel P. Berrangé wrote:
> > > Are you going to take this idea forward and make a formal change proposal
> > > for Fedora to set
On Mon, May 16, 2022 at 07:23:20AM -0700, John Reiser wrote:
> On 5/11/22 19:35, Steve Grubb wrote:
> > On Monday, May 9, 2022 5:10:07 AM EDT Daniel P. Berrangé wrote:
>[snip]
> > > Fast-forward a few months and I see GCC 12.1 is released now with
> > > -ftrivial-auto-var-init option support
On 16/05/2022 16:23, John Reiser wrote:
Please do not use zero as the default auto-init value. Use 0x818181..81
instead.
Fedora only cares about security issues, not about various logical
errors. Setting uninitialized variables to 0 is fine.
Also I think that every such implicit assignment
On 5/16/22 07:33, Michael Catanzaro wrote:
On Mon, May 16 2022 at 07:23:20 AM -0700, John Reiser
wrote:
Zero is the worst possible auto-int value. It will hide the most bugs.
That's true, but using zero also converts code execution vulnerabilities into
denial of service vulnerabilities.
On Mon, May 16 2022 at 07:23:20 AM -0700, John Reiser
wrote:
Zero is the worst possible auto-int value. It will hide the most
bugs.
That's true, but using zero also converts code execution
vulnerabilities into denial of service vulnerabilities. Dereference a
NULL pointer and you get a
On 5/11/22 19:35, Steve Grubb wrote:
On Monday, May 9, 2022 5:10:07 AM EDT Daniel P. Berrangé wrote:
[snip]
Fast-forward a few months and I see GCC 12.1 is released now with
-ftrivial-auto-var-init option support [2].
Are you going to take this idea forward and make a formal change
Hi Steve,
On Wed, 2022-05-11 at 22:35 -0400, Steve Grubb wrote:
> On Monday, May 9, 2022 5:10:07 AM EDT Daniel P. Berrangé wrote:
> > Are you going to take this idea forward and make a formal change proposal
> > for Fedora to set -ftrivial-auto-var-init=zero by default in its default
> > RPM
On Monday, May 9, 2022 5:10:07 AM EDT Daniel P. Berrangé wrote:
> On Fri, Jan 21, 2022 at 01:04:51PM -0500, Steve Grubb wrote:
> > This is a continuation of the discussion from F36 Change: GNU Toolchain
> > Update.
>
> snip.
>
> > He talks about -ftrivial-auto-var-init=zero being used for
Hello,
On Monday, May 9, 2022 5:10:07 AM EDT Daniel P. Berrangé wrote:
> On Fri, Jan 21, 2022 at 01:04:51PM -0500, Steve Grubb wrote:
> > This is a continuation of the discussion from F36 Change: GNU Toolchain
> > Update.
>
> snip.
>
> > He talks about -ftrivial-auto-var-init=zero being used
On Fri, Jan 21, 2022 at 01:04:51PM -0500, Steve Grubb wrote:
> Hello,
>
> This is a continuation of the discussion from F36 Change: GNU Toolchain
> Update.
snip.
> He talks about -ftrivial-auto-var-init=zero being used for production builds
> and -ftrivial-auto-var-init= being used for debug
On Tue, 1 Feb 2022 at 12:03, Florian Weimer wrote:
>
> * Jonathan Wakely:
>
> > Vitaly, it looks like you didn't respond to this. I'm also curious why
> > this change would lead to crashes. Are we missing something?
>
> I've seen cases where access to uninitialized data was fine as long as
> the
* Jonathan Wakely:
> Vitaly, it looks like you didn't respond to this. I'm also curious why
> this change would lead to crashes. Are we missing something?
I've seen cases where access to uninitialized data was fine as long as
the memory location was never zero, something that was always true for
On Sat, 22 Jan 2022 at 14:58, Richard W.M. Jones wrote:
>
> On Sat, Jan 22, 2022 at 12:36:01PM +0100, Vitaly Zaitsev via devel wrote:
> > On 21/01/2022 19:04, Steve Grubb wrote:
> > >Uninitialized variables are a big problem.
> >
> > Yes, but as a package maintainer, I don't want to deal with
On Fri, 28 Jan 2022 at 16:40, Steve Grubb wrote:
>
> >> Of course gcc -fsanitize=undefined cannot be used on production code.
> >
> > Why not? Will it find too many errors?
>
> This discussion is at least 5 years old:
>
> https://seclists.org/oss-sec/2016/q1/363
>
> I don't know if the problems
>> Of course gcc -fsanitize=undefined cannot be used on production code.
>
> Why not? Will it find too many errors?
This discussion is at least 5 years old:
https://seclists.org/oss-sec/2016/q1/363
I don't know if the problems have been addressed or if new problems have
popped up. The short
On Tue, 2022-01-25 at 11:47 -0500, Steve Grubb wrote:
> Hello Dave,
>
> On Tuesday, January 25, 2022 9:29:53 AM EST David Malcolm wrote:
> > Steve, thanks for putting together these cases.
> >
> > I've filed:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104224
> > against the gcc analyzer
Of course gcc -fsanitize=undefined cannot be used on production code.
Why not? Will it find too many errors?
Perhaps because it looks like an ABI change: requires at least
one of /usr/lib64/libasan.so or libubasan.so .
___
devel mailing list --
Hi Mark,
> Of course gcc -fsanitize=undefined cannot be used on production code.
Why not? Will it find too many errors?
Kind regards,
Chris
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
On Thu, Jan 27, 2022 at 11:37:29AM +0100, Mark Wielaard wrote:
> Hi,
>
> On Thu, Jan 27, 2022 at 10:41:36AM +0100, Roberto Ragusa wrote:
> > On 1/22/22 10:05 PM, Mark Wielaard wrote:
> >
> > > So I would give valgrind a 6/6 (100%) score :)
> >
> > But if the compiler starts copying zeros on
Hello Mark,
On Thursday, January 27, 2022 5:37:29 AM EST Mark Wielaard wrote:
> On Thu, Jan 27, 2022 at 10:41:36AM +0100, Roberto Ragusa wrote:
> > On 1/22/22 10:05 PM, Mark Wielaard wrote:
> > > So I would give valgrind a 6/6 (100%) score :)
> >
> > But if the compiler starts copying zeros on
On Thu, Jan 27 2022 at 11:37:29 AM +0100, Mark Wielaard
wrote:
If you believe the tools are pretty good for detecting
these issues (and I believe they are, the example given was just
unfortunate because some of the issues weren't actually bad code and
some others were rightfully optimized out,
On Thu, Jan 27, 2022 at 10:41:36AM +0100, Roberto Ragusa wrote:
> On 1/22/22 10:05 PM, Mark Wielaard wrote:
>
> >So I would give valgrind a 6/6 (100%) score :)
>
> But if the compiler starts copying zeros on uninitialized memory,
> valgrind loses any ability to detect the defect in the code.
Hi,
On Thu, Jan 27, 2022 at 10:41:36AM +0100, Roberto Ragusa wrote:
> On 1/22/22 10:05 PM, Mark Wielaard wrote:
>
> > So I would give valgrind a 6/6 (100%) score :)
>
> But if the compiler starts copying zeros on uninitialized memory,
> valgrind loses any ability to detect the defect in the
On 1/22/22 10:05 PM, Mark Wielaard wrote:
So I would give valgrind a 6/6 (100%) score :)
But if the compiler starts copying zeros on uninitialized memory,
valgrind loses any ability to detect the defect in the code.
Regards.
--
Roberto Ragusamail at robertoragusa.it
Hello Dave,
On Tuesday, January 25, 2022 9:29:53 AM EST David Malcolm wrote:
> Steve, thanks for putting together these cases.
>
> I've filed:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104224
> against the gcc analyzer upstream to help me track improving the
> analyzer on this.
>
> OK if
On Sat, 2022-01-22 at 15:00 -0500, Steve Grubb wrote:
> On Saturday, January 22, 2022 6:36:01 AM EST Vitaly Zaitsev via devel
> wrote:
> > On 21/01/2022 19:04, Steve Grubb wrote:
> > > Uninitialized variables are a big problem.
> >
> > Yes, but as a package maintainer, I don't want to deal with
Mark Wielaard writes:
> Although I am not against trying to turn nondeterministic bugs into
> deterministic ones and getting rid off more undefined code, I am
> slightly worried it means those bugs will be harder to find in
> production. Also I really hope we do also encourage people to use the
Hi Steve,
On Fri, 2022-01-21 at 13:04 -0500, Steve Grubb wrote:
> This is a continuation of the discussion from F36 Change: GNU
> Toolchain Update.
>
> Uninitialized variables are a big problem. They can be sources of information
> exposure if parts of a buffer are not initialized. They can
On Sat, 2022-01-22 at 20:49 +, Richard W.M. Jones wrote:
> On Sat, Jan 22, 2022 at 03:00:14PM -0500, Steve Grubb wrote:
> > On Saturday, January 22, 2022 6:36:01 AM EST Vitaly Zaitsev via
> > devel wrote:
> > > On 21/01/2022 19:04, Steve Grubb wrote:
> > > > Uninitialized variables are a big
On Sat, Jan 22, 2022 at 03:00:14PM -0500, Steve Grubb wrote:
> On Saturday, January 22, 2022 6:36:01 AM EST Vitaly Zaitsev via devel wrote:
> > On 21/01/2022 19:04, Steve Grubb wrote:
> > > Uninitialized variables are a big problem.
> >
> > Yes, but as a package maintainer, I don't want to deal
On 1/22/22 15:00, Steve Grubb wrote:
> On Saturday, January 22, 2022 6:36:01 AM EST Vitaly Zaitsev via devel wrote:
>> On 21/01/2022 19:04, Steve Grubb wrote:
>>> Uninitialized variables are a big problem.
>>
>> Yes, but as a package maintainer, I don't want to deal with dozens of
>> crashes after
On Saturday, January 22, 2022 6:36:01 AM EST Vitaly Zaitsev via devel wrote:
> On 21/01/2022 19:04, Steve Grubb wrote:
> > Uninitialized variables are a big problem.
>
> Yes, but as a package maintainer, I don't want to deal with dozens of
> crashes after this change.
As much as I don't want
On Friday, January 21, 2022 11:26:00 PM EST John Reiser wrote:
> > It might be worthwhile to have a CFLAG that can tell glibc (or other
> > allocators) to substitute something like calloc for malloc.
>
> The environment variable MALLOC_PERTURB_ has been used by glibc malloc
> for over 15 years.
On Sat, Jan 22, 2022 at 12:36:01PM +0100, Vitaly Zaitsev via devel wrote:
> On 21/01/2022 19:04, Steve Grubb wrote:
> >Uninitialized variables are a big problem.
>
> Yes, but as a package maintainer, I don't want to deal with dozens
> of crashes after this change.
>
> Such problems must be fixed
On 21/01/2022 19:04, Steve Grubb wrote:
Uninitialized variables are a big problem.
Yes, but as a package maintainer, I don't want to deal with dozens of
crashes after this change.
Such problems must be fixed by upstream developers, not by volunteers
[package maintainers].
Most upstreams
On Fri, Jan 21, 2022 at 08:26:00PM -0800, John Reiser wrote:
> >It
> >might be worthwhile to have a CFLAG that can tell glibc (or other allocators)
> >to substitute something like calloc for malloc.
>
> The environment variable MALLOC_PERTURB_ has been used by glibc malloc
> for over 15 years.
It
might be worthwhile to have a CFLAG that can tell glibc (or other allocators)
to substitute something like calloc for malloc.
The environment variable MALLOC_PERTURB_ has been used by glibc malloc
for over 15 years.
___
devel mailing list --
On Fri, Jan 21 2022 at 01:04:51 PM -0500, Steve Grubb
wrote:
He said this would have prevented over 900 fixed CVE's in Chrome and
12% of
all Android CVE's.
I believe it. This should be treated like any other security hardening
flag.
Michael
___
Hello,
This is a continuation of the discussion from F36 Change: GNU Toolchain
Update.
Uninitialized variables are a big problem. They can be sources of information
exposure if parts of a buffer are not initialized. They can also cause
unexpected execution paths if the attacker can groom the
40 matches
Mail list logo
