Skip to content
  1. Sep 15, 2018
  2. Sep 13, 2018
  3. Aug 24, 2018
    • Joel Galenson's avatar
      [cfi-verify] Support cross-DSO · 6cc0e63e
      Joel Galenson authored
      When used in cross-DSO mode, CFI will generate calls to special functions rather than trap instructions.  For example, instead of generating
      
      if (!InlinedFastCheck(f))
        abort();
      call *f
      
      CFI generates
      
      if (!InlinedFastCheck(f))
        __cfi_slowpath(CallSiteTypeId, f);
      call *f
      
      This patch teaches cfi-verify to recognize calls to __cfi_slowpath and abort and treat them as trap functions.
      
      In addition to normal symbols, we also parse the dynamic relocations to handle cross-DSO calls in libraries.
      
      We also extend cfi-verify to recognize other patterns that occur using cross-DSO.  For example, some indirect calls are not guarded by a branch to a trap but instead follow a call to __cfi_slowpath.  For example:
      
      if (!InlinedFastCheck(f))
        call *f
      else {
        __cfi_slowpath(CallSiteTypeId, f);
        call *f
      }
      
      In this case, the second call to f is not marked as protected by the current code.  We thus recognize if indirect calls directly follow a call to a function that will trap on CFI violations and treat them as protected.
      
      We also ignore indirect calls in the PLT, since on AArch64 each entry contains an indirect call that should not be protected by CFI, and these are labeled incorrectly when debug information is not present.
      
      Differential Revision: https://reviews.llvm.org/D49383
      
      llvm-svn: 340612
      6cc0e63e
  4. Jul 16, 2018
  5. Jul 13, 2018
    • Joel Galenson's avatar
      [cfi-verify] Support AArch64. · 06e7e579
      Joel Galenson authored
      This patch adds support for AArch64 to cfi-verify.
      
      This required three changes to cfi-verify.  First, it generalizes checking if an instruction is a trap by adding a new isTrap flag to TableGen (and defining it for x86 and AArch64).  Second, the code that ensures that the operand register is not clobbered between the CFI check and the indirect call needs to allow a single dereference (in x86 this happens as part of the jump instruction).  Third, we needed to ensure that return instructions are not counted as indirect branches.  Technically, returns are indirect branches and can be covered by CFI, but LLVM's forward-edge CFI does not protect them, and x86 does not consider them, so we keep that behavior.
      
      In addition, we had to improve AArch64's code to evaluate the branch target of a MCInst to handle calls where the destination is not the first operand (which it often is not).
      
      Differential Revision: https://reviews.llvm.org/D48836
      
      llvm-svn: 337007
      06e7e579
  6. May 09, 2018
  7. Feb 02, 2018
  8. Dec 13, 2017
  9. Dec 05, 2017
    • Shoaib Meenai's avatar
      [CMake] Use PRIVATE in target_link_libraries for executables · d806af34
      Shoaib Meenai authored
      We currently use target_link_libraries without an explicit scope
      specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables.
      Dependencies added in this way apply to both the target and its
      dependencies, i.e. they become part of the executable's link interface
      and are transitive.
      
      Transitive dependencies generally don't make sense for executables,
      since you wouldn't normally be linking against an executable. This also
      causes issues for generating install export files when using
      LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM
      library dependencies, which are currently added as interface
      dependencies. If clang is in the distribution components but the LLVM
      libraries it depends on aren't (which is a perfectly legitimate use case
      if the LLVM libraries are being built static and there are therefore no
      run-time dependencies on them), CMake will complain about the LLVM
      libraries not being in export set when attempting to generate the
      install export file for clang. This is reasonable behavior on CMake's
      part, and the right thing is for LLVM's build system to explicitly use
      PRIVATE dependencies for executables.
      
      Unfortunately, CMake doesn't allow you to mix and match the keyword and
      non-keyword target_link_libraries signatures for a single target; i.e.,
      if a single call to target_link_libraries for a particular target uses
      one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must
      also be updated to use those keywords. This means we must do this change
      in a single shot. I also fully expect to have missed some instances; I
      tested by enabling all the projects in the monorepo (except dragonegg),
      and configuring both with and without shared libraries, on both Darwin
      and Linux, but I'm planning to rely on the buildbots for other
      configurations (since it should be pretty easy to fix those).
      
      Even after this change, we still have a lot of target_link_libraries
      calls that don't specify a scope keyword, mostly for shared libraries.
      I'm thinking about addressing those in a follow-up, but that's a
      separate change IMO.
      
      Differential Revision: https://reviews.llvm.org/D40823
      
      llvm-svn: 319840
      d806af34
  10. Nov 15, 2017
  11. Nov 14, 2017
    • Mitch Phillips's avatar
      [cfi-verify] Add DOT graph printing for GraphResult objects. · 02993892
      Mitch Phillips authored
      Allows users to view GraphResult objects in a DOT directed-graph format. This feature can be turned on through the --print-graphs flag.
      
      Also enabled pretty-printing of instructions in output. Together these features make analysis of unprotected CF instructions much easier by providing a visual control flow graph.
      
      Reviewers: pcc
      
      Subscribers: llvm-commits, kcc, vlad.tsyrklevich
      
      Differential Revision: https://reviews.llvm.org/D39819
      
      llvm-svn: 318211
      02993892
  12. Nov 10, 2017
    • Mitch Phillips's avatar
      [cfi-verify] Made FileAnalysis operate on a GraphResult rather than build one and validate it. · 3b9ea32e
      Mitch Phillips authored
      Refactors the behaviour of building graphs out of FileAnalysis, allowing for analysis of the GraphResult by the callee without having to rebuild the graph. Means when we want to analyse the constructed graph (planned for later revisions), we don't do repeated work.
      
      Also makes CFI verification in FileAnalysis now return an enum that allows us to differentiate why something failed, not just that it did/didn't fail.
      
      Reviewers: vlad.tsyrklevich
      
      Subscribers: kcc, pcc, llvm-commits
      
      Differential Revision: https://reviews.llvm.org/D39764
      
      llvm-svn: 317927
      3b9ea32e
  13. Nov 09, 2017
    • Mitch Phillips's avatar
      [cfi-verify] Adds blacklist blame behaviour to cfi-verify. · d64af525
      Mitch Phillips authored
      Adds the blacklist behaviour to llvm-cfi-verify. Now will calculate which lines caused expected failures in the blacklist and reports the number of affected indirect CF instructions for each blacklist entry.
      
      Also moved DWARF checking after instruction analysis to improve performance significantly - unrolling the inlining stack is expensive.
      
      Reviewers: vlad.tsyrklevich
      
      Subscribers: aprantl, pcc, kcc, llvm-commits
      
      Differential Revision: https://reviews.llvm.org/D39750
      
      llvm-svn: 317743
      d64af525
  14. Nov 06, 2017
  15. Nov 04, 2017
  16. Nov 03, 2017
    • Mitch Phillips's avatar
      [cfi-verify] Add blacklist parsing for result filtering. · c15bdf55
      Mitch Phillips authored
      Adds blacklist parsing behaviour for filtering results into four categories:
      
       - Expected Protected: Things that are not in the blacklist and are protected.
       - Unexpected Protected: Things that are in the blacklist and are protected.
       - Expected Unprotected: Things that are in the blacklist and are unprotected.
       - Unexpected Unprotected: Things that are not in the blacklist and are unprotected.
      
       now can optionally be invoked with a second command line argument, which specifies the blacklist file that the binary was built with.
      
      Current  statistics for chromium:
      
      Reviewers: vlad.tsyrklevich
      
      Subscribers: mgorny, llvm-commits, pcc, kcc
      
      Differential Revision: https://reviews.llvm.org/D39525
      
      llvm-svn: 317364
      c15bdf55
  17. Nov 02, 2017
  18. Nov 01, 2017
    • Mitch Phillips's avatar
      Parse DWARF information to reduce false positives. · 7db6f7a3
      Mitch Phillips authored
      Summary: Help differentiate code and data by parsing DWARF information. This will reduce false positive rates where data is placed in executable sections and is mistakenly parsed as code, resulting in an inflation in the number of indirect CF instructions (and hence an inflation of the number of unprotected).
      
      Also prints the DWARF line data around the region of each indirect CF instruction.
      
      Reviewers: pcc
      
      Subscribers: probinson, llvm-commits, vlad.tsyrklevich, mgorny, aprantl, kcc
      
      Differential Revision: https://reviews.llvm.org/D38654
      
      llvm-svn: 317050
      7db6f7a3
  19. Oct 25, 2017
    • Mitch Phillips's avatar
      Add FileVerifier::isCFIProtected(). · 5ff01cdc
      Mitch Phillips authored
      Add a CFI protection check that is implemented by building a graph and inspecting the output to deduce if the indirect CF instruction is CFI protected. Also added the output of this instruction to printIndirectInstructions().
      
      Reviewers: vlad.tsyrklevich
      
      Subscribers: llvm-commits, kcc, pcc, mgorny
      
      Differential Revision: https://reviews.llvm.org/D38428
      
      llvm-svn: 316610
      5ff01cdc
  20. Oct 24, 2017
  21. Oct 23, 2017
  22. Oct 18, 2017
    • Vlad Tsyrklevich's avatar
      Statically link llvm-cfi-verify's libraries. · 4dc1c973
      Vlad Tsyrklevich authored
      Summary:
      llvm-cfi-verify (D38379) introduced a potential build failure when compiling with `-DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_LINK_LLVM_DYLIB=ON`. Specific versions of cmake seem to treat the `add_subdirectory()` rule differently. It seems as if old versions of cmake BFS these rules, adding them to the fringe for expansion later. Newer versions of cmake seem to immediately execute CMakeFiles that are present in this subdirectory.
      
      If the subdirectory is expanded through the fringe, the globbing resultant from `llvm_add_implicit_projects()` from `cmake/modules/AddLLVM.cmake:1012` means that `tools/llvm-shlib/CMakeFile.txt` gets executed before `tools/llvm-cfi-verify/lib/CMakeFile.txt`. As the latter CMakeFile adds a new library, this expansion order means that the library files required the unit tests in `unittests/tools/llvm-cfi-verify/` are not present in the dynamic library. This causes unit tests to fail as the required functions can't be found.
      
      This change now ensures that the libraries created by `llvm-cfi-verify` are statically linked into the unit tests. As `tools/llvm-cfi-verify/lib` no longer adds anything to `llvm-shlib`, there should be no concern about the order-of-compilation.
      
      Reviewers: skatkov, pcc
      
      Reviewed By: skatkov, pcc
      
      Subscribers: llvm-commits, kcc, pcc, aheejin, vlad.tsyrklevich, mgorny
      
      Differential Revision: https://reviews.llvm.org/D39020
      
      llvm-svn: 316059
      4dc1c973
  23. Oct 12, 2017
  24. Oct 11, 2017
  25. Oct 10, 2017
    • Vlad Tsyrklevich's avatar
      Revert "Classify llvm-cfi-verify." · a45919f5
      Vlad Tsyrklevich authored
      This reverts commit r315363. It has a simple build failure, but more
      importantly I want to confirm that unit tests run in check-all to make
      sure that they don't silently break in the future.
      
      llvm-svn: 315370
      a45919f5
    • Vlad Tsyrklevich's avatar
      Classify llvm-cfi-verify. · b5488a22
      Vlad Tsyrklevich authored
      Summary: Move llvm-cfi-verify into a class in preparation for CFI analysis to come.
      
      Reviewers: vlad.tsyrklevich
      
      Reviewed By: vlad.tsyrklevich
      
      Subscribers: mgorny, llvm-commits, pcc, kcc
      
      Differential Revision: https://reviews.llvm.org/D38379
      
      llvm-svn: 315363
      b5488a22
  26. Sep 20, 2017
Loading