On Wed, Aug 9, 2023 at 1:33 PM Siddhesh Poyarekar <siddh...@gotplt.org> wrote:
> 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 > Hi, Sid Thanks for iterating on this. > > """ > 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. > Should we direct people to the upstream projects for their security policies? > 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. > As Richard mentioned, should GCC make a specific statement about the security policy / response for issues that are discovered and fixed in the upstream projects from which the GCC libraries are imported? > > 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. > Thanks, David
