llvm/docs/SecurityTransparencyReports.rst

   1 ========================================
   2 LLVM Security Group Transparency Reports
   3 ========================================
   4
   5 This page lists the yearly LLVM Security group transparency reports.
   6
   7 2021
   8 ----
   9
  10 The :doc:`LLVM security group <Security>` was established on the 10th of July
  11 2020 by the act of the `initial
  12 commit <https://github.com/llvm/llvm-project/commit/7bf73bcf6d93>`_ describing
  13 the purpose of the group and the processes it follows.  Many of the group's
  14 processes were still not well-defined enough for the group to operate well.
  15 Over the course of 2021, the key processes were defined well enough to enable
  16 the group to operate reasonably well:
  17
  18 * We defined details on how to report security issues, see `this commit on
  19   20th of May 2021 <https://github.com/llvm/llvm-project/commit/c9dbaa4c86d2>`_
  20 * We refined the nomination process for new group members, see `this
  21   commit on 30th of July 2021 <https://github.com/llvm/llvm-project/commit/4c98e9455aad>`_
  22 * We started writing an annual transparency report (you're reading the 2021
  23   report here).
  24
  25 Over the course of 2021, we had 2 people leave the LLVM Security group and 4
  26 people join.
  27
  28 In 2021, the security group received 13 issue reports that were made publicly
  29 visible before 31st of December 2021.  The security group judged 2 of these
  30 reports to be security issues:
  31
  32 * https://bugs.chromium.org/p/llvm/issues/detail?id=5
  33 * https://bugs.chromium.org/p/llvm/issues/detail?id=11
  34
  35 Both issues were addressed with source changes: #5 in clangd/vscode-clangd, and
  36 #11 in llvm-project.  No dedicated LLVM release was made for either.
  37
  38 We believe that with the publishing of this first annual transparency report,
  39 the security group now has implemented all necessary processes for the group to
  40 operate as promised. The group's processes can be improved further, and we do
  41 expect further improvements to get implemented in 2022. Many of the potential
  42 improvements end up being discussed on the `monthly public call on LLVM's
  43 security group <https://llvm.org/docs/GettingInvolved.html#online-sync-ups>`_.
  44
  45
  46 2022
  47 ----
  48
  49 In this section we report on the issues the group received in 2022, or on issues
  50 that were received earlier, but were disclosed in 2022.
  51
  52 In 2022, the llvm security group received 15 issues that have been disclosed at
  53 the time of writing this transparency report.
  54
  55 5 of these were judged to be security issues:
  56
  57 * https://bugs.chromium.org/p/llvm/issues/detail?id=17 reports a miscompile in
  58   LLVM that can result in the frame pointer and return address being
  59   overwritten. This was fixed.
  60
  61 * https://bugs.chromium.org/p/llvm/issues/detail?id=19 reports a vulnerability
  62   in `std::filesystem::remove_all` in libc++. This was fixed.
  63
  64 * https://bugs.chromium.org/p/llvm/issues/detail?id=23 reports a new Spectre
  65   gadget variant that Speculative Load Hardening (SLH) does not mitigate. No
  66   extension to SLH was implemented to also mitigate against this variant.
  67
  68 * https://bugs.chromium.org/p/llvm/issues/detail?id=30 reports missing memory
  69   safety protection on the (C++) exception handling path. A number of fixes
  70   were implemented.
  71
  72 * https://bugs.chromium.org/p/llvm/issues/detail?id=33 reports the RETBLEED
  73   vulnerability. The outcome was clang growing a new security hardening feature
  74   `-mfunction-return=thunk-extern`, see https://reviews.llvm.org/D129572.
  75
  76
  77 No dedicated LLVM releases were made for any of the above issues.
  78