Re: [PATCH] Add a GCC Security policy
On 2023-09-20 08:29, Jakub Jelinek wrote: I just noticed (ENOCOFFEE) that the line (after removing libvtv) is: Support libraries such as libiberty, libcc1 and libcpp have been developed separately to share code with other tools such as binutils and gdb. Does that address your concern Jakub? I believe that is the case just for libiberty. libcpp is I think solely used by gcc itself (several frontends use it though, plus some build utilities in gcc). libcc1 is code for gdb with gcc implementation details. How about: Libraries that are not distributed for runtime language support such as libiberty, libcc1 and libcpp have similar challenges to compiler drivers. While they are expected to be robust against arbitrary input, they should only be used with trusted inputs. Thanks, Sid
Re: [PATCH] Add a GCC Security policy
On Wed, Sep 20, 2023 at 08:23:32AM -0400, Siddhesh Poyarekar wrote: > On 2023-09-20 07:58, Siddhesh Poyarekar wrote: > > On 2023-09-20 07:55, Jakub Jelinek wrote: > > > On Wed, Sep 20, 2023 at 07:50:43AM -0400, Siddhesh Poyarekar wrote: > > > > + Support libraries such as libiberty, libcc1 libvtv and libcpp have > > > > > > Missing comma before libvtv. But more importantly, libvtv is not > > > support library like libiberty, libcpp, it is more like the sanitizer > > > libraries runtime library for -fvtable-verify= . > > > > Ack, I'll move libvtv out. > > > > > And, libcc1 also isn't a compiler support library, but support library > > > for a GDB plugin. > > > > > > > Isn't that like libiberty then, which also gets used by other toolchain > > projects? Maybe calling it "Toolchain support libraries" would make it > > more explicit? > > I just noticed (ENOCOFFEE) that the line (after removing libvtv) is: > > Support libraries such as libiberty, libcc1 and libcpp have been > developed separately to share code with other tools such as binutils > and gdb. > > Does that address your concern Jakub? I believe that is the case just for libiberty. libcpp is I think solely used by gcc itself (several frontends use it though, plus some build utilities in gcc). libcc1 is code for gdb with gcc implementation details. Jakub
Re: [PATCH] Add a GCC Security policy
On Wed, Sep 20, 2023 at 07:58:04AM -0400, Siddhesh Poyarekar wrote: > On 2023-09-20 07:55, Jakub Jelinek wrote: > > On Wed, Sep 20, 2023 at 07:50:43AM -0400, Siddhesh Poyarekar wrote: > > > +Support libraries such as libiberty, libcc1 libvtv and libcpp have > > > > Missing comma before libvtv. But more importantly, libvtv is not > > support library like libiberty, libcpp, it is more like the sanitizer > > libraries runtime library for -fvtable-verify= . > > Ack, I'll move libvtv out. > > > And, libcc1 also isn't a compiler support library, but support library > > for a GDB plugin. > > > > Isn't that like libiberty then, which also gets used by other toolchain > projects? Maybe calling it "Toolchain support libraries" would make it more > explicit? Not really. libiberty is a static only library with some useful routines for all the projects which each of them links in. libcc1 is a shared library which gdb uses to implement the eval command (or how is it called). Jakub
Re: [PATCH] Add a GCC Security policy
On 2023-09-20 07:58, Siddhesh Poyarekar wrote: On 2023-09-20 07:55, Jakub Jelinek wrote: On Wed, Sep 20, 2023 at 07:50:43AM -0400, Siddhesh Poyarekar wrote: + Support libraries such as libiberty, libcc1 libvtv and libcpp have Missing comma before libvtv. But more importantly, libvtv is not support library like libiberty, libcpp, it is more like the sanitizer libraries runtime library for -fvtable-verify= . Ack, I'll move libvtv out. And, libcc1 also isn't a compiler support library, but support library for a GDB plugin. Isn't that like libiberty then, which also gets used by other toolchain projects? Maybe calling it "Toolchain support libraries" would make it more explicit? I just noticed (ENOCOFFEE) that the line (after removing libvtv) is: Support libraries such as libiberty, libcc1 and libcpp have been developed separately to share code with other tools such as binutils and gdb. Does that address your concern Jakub? Thanks, Sid
Re: [PATCH] Add a GCC Security policy
On 2023-09-20 07:55, Jakub Jelinek wrote: On Wed, Sep 20, 2023 at 07:50:43AM -0400, Siddhesh Poyarekar wrote: +Support libraries such as libiberty, libcc1 libvtv and libcpp have Missing comma before libvtv. But more importantly, libvtv is not support library like libiberty, libcpp, it is more like the sanitizer libraries runtime library for -fvtable-verify= . Ack, I'll move libvtv out. And, libcc1 also isn't a compiler support library, but support library for a GDB plugin. Isn't that like libiberty then, which also gets used by other toolchain projects? Maybe calling it "Toolchain support libraries" would make it more explicit? Thanks, Sid
Re: [PATCH] Add a GCC Security policy
On Wed, Sep 20, 2023 at 07:50:43AM -0400, Siddhesh Poyarekar wrote: > +Support libraries such as libiberty, libcc1 libvtv and libcpp have Missing comma before libvtv. But more importantly, libvtv is not support library like libiberty, libcpp, it is more like the sanitizer libraries runtime library for -fvtable-verify= . And, libcc1 also isn't a compiler support library, but support library for a GDB plugin. Jakub
[PATCH] Add a GCC Security policy
Define a security process and exclusions to security issues for GCC and all components it ships. Signed-off-by: Siddhesh Poyarekar --- Sending as a proper patch since there have been no further comments on the RFC. I toyed with the idea of making the distinction of "exploitable vulnerability" vs "missed hardening" more explicit near the top of the document but decided against further tinkering in the end since we already have a proper section dealing with it. Instead I made the language in the hardening section a bit more explicit, clarifying that missed hardening is not an *exploitable vulnerability*, which hopefully resolves the contradication of a bug in a security feature not being a security bug. I also added the AdaCore security contact at Arnaud's request. Thanks, Sid SECURITY.txt | 202 +++ 1 file changed, 202 insertions(+) create mode 100644 SECURITY.txt diff --git a/SECURITY.txt b/SECURITY.txt new file mode 100644 index 000..d2161f03bf5 --- /dev/null +++ b/SECURITY.txt @@ -0,0 +1,202 @@ +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. Compiling untrusted +sources can result in arbitrary code execution and unconstrained +resource consumption in the compiler. As a result, compilation of +such code should be done inside a sandboxed environment to ensure +that it does not compromise the development environment. + +The libgccjit library can, despite the name, be used both for +ahead-of-time compilation and for just-in-compilation. In both +cases it can be used to translate input representations (such as +source code) in the application context; in the latter case the +generated code is also run in the application context. + +Limitations that apply to the compiler driver, apply here too in +terms of sanitizing inputs and it is recommended that both the +compilation *and* execution context of the code are appropriately +sandboxed to contain the effects of any bugs in libgccjit, the +application code using it, 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 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. However if you find an issue in +these libraries independent of their use in GCC, you should reach +out to their upstream projects to report them. + +As a result, the only case for a potential security issue in the +compiler is when it generates vulnerable application code for +trusted input source code that is conforming to the relevant +programming standard or extensions documented as supported by GCC +and the algorithm expressed in the source code does not have the +vulnerability. 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 severe enough to amount to a denial of service. +- The application crashes due to the generated incorrect code, + resulting in a Denial of Service. + +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: +
