> On Aug 11, 2023, at 10:36 AM, Siddhesh Poyarekar <siddh...@gotplt.org> wrote:
>
> On 2023-08-10 14:50, Siddhesh Poyarekar wrote:
>>>> As a result, the only case for a potential security issue in all
>>>> these cases is when it ends up generating vulnerable output for
>>>> valid input source code.
>>>
>>> I think this leaves open the interpretation "every wrong code bug
>>> is potentially a security bug". I suppose that's true in a trite sense,
>>> but not in a useful sense. As others said earlier in the thread,
>>> whether a wrong code bug in GCC leads to a security bug in the object
>>> code is too application-dependent to be a useful classification for GCC.
>>>
>>> I think we should explicitly say that we don't generally consider wrong
>>> code bugs to be security bugs. Leaving it implicit is bound to lead
>>> to misunderstanding.
>> I see what you mean, but the context-dependence of a bug is something GCC
>> will have to deal with, similar to how libraries have to deal with bugs.
>> But I agree this probably needs some more expansion. Let me try and come up
>> with something more detailed for that last paragraph.
>
> How's this:
>
> As a result, the only case for a potential security issue in the compiler is
> when it generates vulnerable application code for valid, trusted input source
> code. The output application code could be considered vulnerable if it
> produces an actual vulnerability in the target application, specifically in
> the following cases:
You might make it explicit that we're talking about wrong code errors here --
in other words, the source code is correct (conforms to the standard) and the
algorithm expressed in the source code does not have a vulnerability, but the
generated code has semantics that differ from those of the source code such
that it does have a vulnerability.
> - The application dereferences an invalid memory location despite the
> application sources being valid.
>
> - The application reads from or writes to a valid but incorrect memory
> location, resulting in an information integrity issue or an information leak.
>
> - The application ends up running in an infinite loop or with severe
> degradation in performance despite the input sources having no such issue,
> resulting in a Denial of Service. Note that correct but non-performant code
> is not a security issue candidate, this only applies to incorrect code that
> may result in performance degradation.
The last sentence somewhat contradicts the preceding one. Perhaps "...may
result in performance degradation severe enough to amount to a denial of
service".
> - The application crashes due to the generated incorrect code, resulting in a
> Denial of Service.
paul
