On 07/24/2018 01:59 AM, Bernd Edlinger wrote: > Hi! > > 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, what code?
> > 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 user code". 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. Thanks, Jeff
