On 2023-08-08 10:30, Siddhesh Poyarekar wrote:
Do you have a suggestion for the language to address libgcc,
libstdc++, etc. and libiberty, libbacktrace, etc.?
I'll work on this a bit and share a draft.
Hi David,
Here's what I came up with for different parts of GCC, including the
runtime libraries. Over time we may find that specific parts of runtime
libraries simply cannot be used safely in some contexts and flag that.
Sid
"""
What is a GCC security bug?
===========================
A security bug is one that threatens the security of a system or
network, or might compromise the security of data stored on it.
In the context of GCC there are multiple ways in which this might
happen and they're detailed below.
Compiler drivers, programs, libgccjit and support libraries
-----------------------------------------------------------
The compiler driver processes source code, invokes other programs
such as the assembler and linker and generates the output result,
which may be assembly code or machine code. It is necessary that
all source code inputs to the compiler are trusted, since it is
impossible for the driver to validate input source code beyond
conformance to a programming language standard.
The GCC JIT implementation, libgccjit, is intended to be plugged
into applications to translate input source code in the application
context. Limitations that apply to the compiler
driver, apply here too in terms of sanitizing inputs, so it is
recommended that inputs are either sanitized by an external program
to allow only trusted, safe execution in the context of the
application or the JIT execution context is appropriately sandboxed
to contain the effects of any bugs in the JIT or its generated code
to the sandboxed environment.
Support libraries such as libiberty, libcc1 libvtv and libcpp have
been developed separately to share code with other tools such as
binutils and gdb. These libraries again have similar challenges to
compiler drivers. While they are expected to be robust against
arbitrary input, they should only be used with trusted inputs.
Libraries such as zlib and libffi that bundled into GCC to build it
will be treated the same as the compiler drivers and programs as far
as security coverage is concerned.
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.
Language runtime libraries
--------------------------
GCC also builds and distributes libraries that are intended to be
used widely to implement runtime support for various programming
languages. These include the following:
* libada
* libatomic
* libbacktrace
* libcc1
* libcody
* libcpp
* libdecnumber
* libgcc
* libgfortran
* libgm2
* libgo
* libgomp
* libiberty
* libitm
* libobjc
* libphobos
* libquadmath
* libssp
* libstdc++
These libraries are intended to be used in arbitrary contexts and as
a result, bugs in these libraries may be evaluated for security
impact. However, some of these libraries, e.g. libgo, libphobos,
etc. are not maintained in the GCC project, due to which the GCC
project may not be the correct point of contact for them. You are
encouraged to look at README files within those library directories
to locate the canonical security contact point for those projects.
Diagnostic libraries
--------------------
The sanitizer library bundled in GCC is intended to be used in
diagnostic cases and not intended for use in sensitive environments.
As a result, bugs in the sanitizer will not be considered security
sensitive.
GCC plugins
-----------
It should be noted that GCC may execute arbitrary code loaded by a
user through the GCC plugin mechanism or through system preloading
mechanism. Such custom code should be vetted by the user for safety
as bugs exposed through such code will not be considered security
issues.
