This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Make strlen range computations more conservative
- From: Jeff Law <law at redhat dot com>
- To: Bernd Edlinger <bernd dot edlinger at hotmail dot de>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Cc: Richard Biener <rguenther at suse dot de>, Jakub Jelinek <jakub at redhat dot com>
- Date: Tue, 24 Jul 2018 15:46:45 -0600
- Subject: Re: [PATCH] Make strlen range computations more conservative
- References: <AM5PR0701MB2657A771EAD27A906CE47D0AE4550@AM5PR0701MB2657.eurprd07.prod.outlook.com>
On 07/24/2018 01:59 AM, Bernd Edlinger wrote:
> This patch makes strlen range computations more conservative.
> Firstly if there is a visible type cast from type A to B before passing
> then value to strlen, don't expect the type layout of B to restrict the
> possible return value range of strlen.
Why do you think this is the right thing to do? ie, is there language
in the standards that makes you think the code as it stands today is
incorrect from a conformance standpoint? Is there a significant body of
code that is affected in an adverse way by the current code? If so,
> Furthermore use the outermost enclosing array instead of the
> innermost one, because too aggressive optimization will likely
> convert harmless errors into security-relevant errors, because
> as the existing test cases demonstrate, this optimization is actively
> attacking string length checks in user code, while and not giving
> any warnings.
Same questions here.
I'll also note that Martin is *very* aware of the desire to avoid
introducing security relevent errors. In fact his main focus is to help
identify coding errors that have a security impact. So please don't
characterize his work as "actively attacking string length checks in
Ultimately we want highly accurate string lengths to help improve the
quality of the warnings we generate for potentially dangerous code.
These changes seem to take us in the opposite direction.
So ISTM that you really need a stronger justification using the
standards compliance and/or real world code that is made less safe by
keeping string lengths as accurate as possible.
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?
I'd like to ask we hold on this until I return from PTO (Aug 1) so that
we can discuss the best thing to do here for each class of change.
I think you, Martin, Richi and myself should hash through the technical
issues raised by the patch. Obviously others can chime in, but I think
the 4 of us probably need to drive the discussion.