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:
- 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 application crashes due to the generated incorrect code, resulting
in a Denial of Service.
