1. 07 Sep, 2017 1 commit
    • Andreas Haas's avatar
      [wasm] Avoid executing infinite loops in the wasm fuzzers · 7b53a0e0
      Andreas Haas authored
      The wasm-async fuzzer uses the bytes provided by the fuzzer engine
      directly as wasm module bytes, compiles them with async compilation, and
      then tries to execute the "main" function of the module. This "main"
      can have an infinite loop which causes a timeout in the fuzzer. With
      this CL the "main" function is first executed with the interpreter. If
      the execution in the interpreter finishes within 16k steps, which means
      that there is no infinite loop, also the compiled code is executed.
      
      I added the raw fuzzer input as a test case because in this case I
      really want to test the fuzzer and not V8.
      
      R=clemensh@chromium.org
      
      Bug: chromium:761784
      Change-Id: Id1fe5da0da8670ec821ab9979fdb9454dbde1162
      Reviewed-on: https://chromium-review.googlesource.com/651046
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47874}
      7b53a0e0
  2. 21 Jun, 2017 1 commit
  3. 13 Jun, 2017 1 commit
  4. 08 May, 2017 1 commit
  5. 17 Feb, 2017 1 commit
    • eholk's avatar
      [wasm] Syntax- and Type-aware Fuzzer · 3e1db847
      eholk authored
      This is the beginning of a new fuzzer that generates
      correct-by-construction Wasm modules. This should allow us to better
      exercise the compiler and correctness aspects of fuzzing. It is based off
      of ahaas' original Wasm fuzzer.
      
      At the moment, it can generate expressions made up of most binops, and
      also nested blocks with unconditional breaks. Future CLs will add
      additional constructs, such as br_if, loops, memory access, etc.
      
      The way the fuzzer works is that it starts with an array of arbitrary
      data provided by libfuzzer. It uses the data to generate an expression.
      Care is taken to make use of the entire string. Basically, the
      generator has a bunch of grammar-like rules for how to construct an
      expression of a given type. For example, an i32 can be made by adding
      two other i32s, or by wrapping an i64. The process then continues
      recursively until all the data is consumed.
      
      We generate an expression from a slice of data as follows:
      * If the slice is less than or equal to the size of the type (e.g. 4
        bytes for i32), then it will emit the entire slice as a constant.
      * Otherwise, it will consume the first 4 bytes of the slice and use
        this to select which rule to apply. Each rule then consumes the
        remainder of the slice in an appropriate way. For example:
        * Unary ops use the remainder of the slice to generate the argument.
        * Binary ops consume another four bytes and mod this with the length
          of the remaining slice to split the slice into two parts. Each of
          these subslices are then used to generate one of the arguments to
          the binop.
        * Blocks are basically like a unary op, but a stack of block types is
          maintained to facilitate branches. For blocks that end in a break,
          the first four bytes of a slice are used to select the break depth
          and the stack determines what type of expression to generate.
      The goal is that once this generator is complete, it will provide a one
      to one mapping between binary strings and valid Wasm modules.
      
      Review-Url: https://codereview.chromium.org/2658723006
      Cr-Commit-Position: refs/heads/master@{#43289}
      3e1db847
  6. 18 Nov, 2016 1 commit
  7. 24 Oct, 2016 1 commit
  8. 14 Oct, 2016 1 commit
  9. 13 Oct, 2016 1 commit
  10. 07 Oct, 2016 1 commit
  11. 05 Oct, 2016 3 commits
  12. 04 Oct, 2016 2 commits
  13. 26 Sep, 2016 1 commit
    • jgruber's avatar
      Enable component builds for fuzzers · 22606f0c
      jgruber authored
      V8 is collecting a growing amount of fuzzers, all of which take substantial
      space on the bots and in chromium build archives. This CL improves that
      situation by allowing component (shared library) builds for almost all fuzzers.
      
      The parser fuzzer is handled as an exception since it would require exporting a
      large number of additional functions.
      
      A component build results in about a 50-100x improvement in file size for each
      fuzzer (~50M-100M to around 1.1M).
      
      BUG=chromium:648864
      CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe
      
      Review-Url: https://codereview.chromium.org/2360983002
      Cr-Commit-Position: refs/heads/master@{#39709}
      22606f0c
  14. 19 Sep, 2016 1 commit
  15. 14 Sep, 2016 2 commits
    • ahaas's avatar
      [wasm] Write fuzzers for single wasm sections. · 3ff20190
      ahaas authored
      This CL adds fuzzers for the wasm module sections 'types', 'names',
      'globals', 'imports', 'function signatures', 'memory', and 'data', one
      fuzzer per section. No fuzzers are added for the other sections because
      either there already exists a fuzzer (e.g. wasm-code), or there exist
      inter-section dependencies.
      
      To avoid introducing a bunch executables which would make compilation
      with make slow, I introduce a single executable
      'v8_simple_wasm_section_fuzzer' which calls the fuzzers mentioned above.
      This executable is run by the trybots and ensures that the fuzzers
      actually compile. For debugging I introduce commandline parameters which
      allow to execute the specific fuzzers from 'v8_simple_wasm_section_fuzzer'.
      
      R=titzer@chromium.org, jochen@chromium.org, mstarzinger@chromium.org
      
      Review-Url: https://codereview.chromium.org/2336603002
      Cr-Commit-Position: refs/heads/master@{#39413}
      3ff20190
    • ahaas's avatar
      [wasm] Move the wasm-module-runner from test/cctest to test/common · cc7926d6
      ahaas authored
      The wasm-module-runner is used both in cctests and in fuzzers. As
      discussed offline, it is weird to include cctest header files in
      fuzzers, so I introduce a new test/common directory which contains the
      common files.
      
      R=titzer@chromium.org, jochen@chromium.org
      
      Review-Url: https://codereview.chromium.org/2335193002
      Cr-Commit-Position: refs/heads/master@{#39411}
      cc7926d6
  16. 12 Sep, 2016 1 commit
    • ahaas's avatar
      [wasm] Call the wasm interpreter from the wasm-code-fuzzer. · 1521fe9c
      ahaas authored
      With this CL the wasm-code-fuzzer first decodes and interprets the test
      case generated by the fuzzer. It then compiles the test case, but only
      executes the compiled instance if the interpretation of the test case
      was successful. If the compiled instance is executed, then the result of
      the execution is compared with the result of the interpretation.
      
      Additionally this CL refactors the CompileAndRunWasmModule function in
      wasm-module.cc to resuse code in the call to the interpreter.
      
      R=titzer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2321443002
      Cr-Commit-Position: refs/heads/master@{#39351}
      1521fe9c
  17. 29 Aug, 2016 1 commit
  18. 03 Jun, 2016 1 commit
    • machenbach's avatar
      [gn] Add fuzzer targets. · 63526069
      machenbach authored
      This adds the v8-side fuzzer executables for smoke testing.
      This also renames the old gyp targets to stay consistent
      with chromium.
      
      Naming convention for type X after the rename:
      library: X_fuzzer (gn), X_fuzzer_lib (gyp)
      executable v8: v8_simple_X_fuzzer
      executable chromium: v8_X_fuzzer
      
      BUG=chromium:474921
      
      Review-Url: https://codereview.chromium.org/2032363002
      Cr-Commit-Position: refs/heads/master@{#36713}
      63526069
  19. 29 Apr, 2016 1 commit
  20. 25 Apr, 2016 1 commit
    • machenbach's avatar
      [build] Prepare moving v8.gyp to src/ · cb855fe7
      machenbach authored
      This will allow to pull in gyp as a deps to the same location
      as chromium (tools/gyp not build/gyp), needed for gn switch.
      
      This is the first step of a 3-way move.
      1) Copy v8.gyp in v8
      2) Update references in embedders (follow up)
      3) Remove old v8.gyp (follow up)
      
      BUG=chromium:474921
      LOG=n
      NOTRY=true
      
      Review URL: https://codereview.chromium.org/1920793002
      
      Cr-Commit-Position: refs/heads/master@{#35760}
      cb855fe7
  21. 02 Mar, 2016 1 commit
  22. 02 Feb, 2016 1 commit
  23. 01 Feb, 2016 1 commit
  24. 26 Jan, 2016 1 commit