Proto commits in googleprojectzero/fuzzilli

These commits are when the Protocol Buffers files have changed: (only the last 100 relevant commits are shown)

2025-01-30

[wasm] Add more simd load instructions Note that there are even more simd load instructions (those with "extract lane") but they have different signatures, so they will need separate Fuzzilli nodes and therefore are not included in this change. Bug: chromium:391916477 Change-Id: Iab3f1be0e0c640445ec181240508c2ee0228edab Reviewed-on: https://chrome-internal-review.googlesource.com/c/v8/fuzzilli/+/7988888 Reviewed-by: Carl Smith <cffsmith@google.com> Reviewed-by: Eva Herencsárová <evih@google.com> Commit-Queue: Matthias Liedtke <mliedtke@google.com>

The documentation is generated from this commit.

2025-01-22

[wasm] Add support for try-catch blocks with result Change-Id: Iddb7a57b15a25cd7c4eff9b1ac1293670ddf070e Reviewed-on: https://chrome-internal-review.googlesource.com/c/v8/fuzzilli/+/7970030 Commit-Queue: Matthias Liedtke <mliedtke@google.com> Reviewed-by: Carl Smith <cffsmith@google.com>

2025-01-20

[wasm] Restructure try-catch blocks in Fuzzilli Previously, the wasm try catch would look somewhat like this in FuzzIL: try -> L:v1 throw v2 v3 = 123 catch v2 -> v4 // v3 is visible here but it may not be initialized. endcatch // the code generator might still insert more regular wasm // statements here... endtry This CL changes that to: try -> L:v1 throw v2 v3 = 123 catch v2 -> L:v4 v5 // v3 is not visible here. endtry where the catch block finishes the try block and starts a new block at the same time (for the catch content). The endtry therefore is an end block for either `try`, `catch`, or `catch_all`. Change-Id: If61b1c4fd99c630c1fb879cd4db310d7c5509018 Reviewed-on: https://chrome-internal-review.googlesource.com/c/v8/fuzzilli/+/7967834 Reviewed-by: Carl Smith <cffsmith@google.com> Commit-Queue: Matthias Liedtke <mliedtke@google.com>

[wasm] Add support for loops with parameters and result value Change-Id: Ia53e92e8f50e5e26ee93d4ef27e57f5d995b6d26 Reviewed-on: https://chrome-internal-review.googlesource.com/c/v8/fuzzilli/+/7967833 Reviewed-by: Carl Smith <cffsmith@google.com> Commit-Queue: Matthias Liedtke <mliedtke@google.com>

[wasm] Add support for if else blocks with result Change-Id: Idd76862352cea3bbbbc62c4d0b4e4c3556245c04 Reviewed-on: https://chrome-internal-review.googlesource.com/c/v8/fuzzilli/+/7967832 Reviewed-by: Carl Smith <cffsmith@google.com> Commit-Queue: Matthias Liedtke <mliedtke@google.com>

[wasm] Add support for blocks with result This changes wasm blocks (only the "plain" block, not ifs, trys etc.) to have an optional result type. A wasm block with a result produces a Variable in its WasmEndBlock operation. The value is either the input argument to the WasmEndBlock (in case of regularly reaching the end of the block) or the arguments passed into a WasmBranch or WasmBranchIf operation that branches to the WasmBeginBlock's label. As these branch instructions need to provide the argument(s) matching the block signature, the label type is extended to also contain type information about the arguments to be passed along a branch. Change-Id: I4a1af782330c7a71320a2d4b1949dba081d1d4de Reviewed-on: https://chrome-internal-review.googlesource.com/c/v8/fuzzilli/+/7967831 Reviewed-by: Carl Smith <cffsmith@google.com> Commit-Queue: Matthias Liedtke <mliedtke@google.com>

[wasm] Add parameters and labels to if and else blocks Change-Id: I2af6c8b312f697982e7c0f7f88572d82e9e81d68 Reviewed-on: https://chrome-internal-review.googlesource.com/c/v8/fuzzilli/+/7967829 Reviewed-by: Carl Smith <cffsmith@google.com> Commit-Queue: Matthias Liedtke <mliedtke@google.com>

Add wasm select instruction Change-Id: I69614762932b78d3d05d87528439035872d3bb90 Reviewed-on: https://chrome-internal-review.googlesource.com/c/v8/fuzzilli/+/7963008 Auto-Submit: Matthias Liedtke <mliedtke@google.com> Reviewed-by: Carl Smith <cffsmith@google.com> Commit-Queue: Matthias Liedtke <mliedtke@google.com>

2025-01-17

[simd][memory64] Introduce wasmI64x2LoadSplat instruction and generator This instruction is a SIMD instruction that needs a memory argument. It is also adjusted to work on memory64. This change also removes using OOB offsets for memory access generators. Change-Id: I76d8c1f97646abdcc5ed07d241458ae70c4765f6 Reviewed-on: https://chrome-internal-review.googlesource.com/c/v8/fuzzilli/+/7960346 Commit-Queue: Eva Herencsárová <evih@google.com> Reviewed-by: Carl Smith <cffsmith@google.com>

2025-01-14

[memory64] Adjust operations, generators to support memory64 After this change the fuzzer should be able to generate memory64 and the exact same instructions on memory64 as on memory32.

Introduce BindMethod Introduce a new IL instruction that we can use to call methods from WebAssembly. In order for this to work, we need to bind .call on the method: const unboundSlice = Array.prototype.slice; const slice = Function.prototype.call.bind(unboundSlice); // We can now call .slice() and pass the this parameter as a first // argument. This allows us to perform the slice method call from // WebAssembly by passing the this parameter as a first externref // argument.

Introduce the WasmTableType WasmTypeExtension

Add wasm tables with initializers

Add wasm rethrow operation

Add wasm try-delegate

Add tag definitions to wasm module

2025-01-13

Add wasm throw operation and wire up with catch blocks

Add user-space WebAssembly tags to JavaScript These will later on be imported by the WebAssembly module to generate throw and catch statements using these tags. We will also need a similar mechanism to define tags inside WebAssembly later on.

Add wasm catch block for WebAssembly.JSTag

Add WebAssembly.JSTag Right now this only adds the JavaScript-side variable that can then be imported later on into a Wasm module and used inside catch operations.

Simplify WasmLifter We now pass a typer into the WasmLifter that re-types the JavaScript program during lifting. This is now a typer that might have less information than we had during program building as any setType operation in a template will be lost. This does enable us to query the typer for the types of variables that we need to import. Specifically we can now easily use the WasmTypeExtensions to get additional information that we need during lifting. We can therefore also get rid of the import generators.

Add WasmMemoryStore/Load operations and generators This change extends the WasmMemoryStore/Load WasmOperations to be able to generate all (non-simd) memory accessing Wasm instructions.

Fix Simd128 type serialization

Add Wasm unreachable

Add Wasm catch_all block

Added Wasm simd128 float unary and binary operations

Rename Wasm memory get/set to load/store

Use WasmMemoryType type extensions for memories This change: - Introduces the WasmMemoryType. This is used as a WasmTypeExtension when creating Wasm memories which are of type ILType.object. Operations using this type were adjusted. - Adds a macro instruction to create Wasm memories in JS that are imported to the Wasm module. - Adds a generator for the macro instruction. The WasmMemoryType allows to define shared and memory64 memories. The WasmLifting is not adjusted and there are no generators/templates for them yet.

[wasm] Add support for SIMD operations In particular: - Const - Compare - Integer Unary - Integer Binary - i64x2ExtractLane - i64x2Splat Change-Id: If650b3ff5cea51e8f1b21c54102da340c2f25d4b

Add wasm try block Add support for try blocks (for try-catch, but doesn't include any catch statements yet).

Implement JSPI fuzzing We can now wrap functions for JSPI usage in Wasm as well as wrap exports from Wasm modules.

Add more WasmGenerators and WasmProgramTemplates. Specifically add a WasmJsCall-, WasmBlock- and WasmLoopGenerator. Also add a way to convert JS world function signatures into Wasm compatible function signatures by mapping JS types to their Wasm counterparts and select types at random if we cannot find a counterpart. Add four new ProgramTemplates; two that generate WasmCode and two that mix Wasm and JavaScript.

Implement saturating truncations for floats.

Implement numerical conversion operations.

Move Wasm generators to a separate file. misc. small fixes and changes to generation.

Add basic numerical instructions. ... and clean up some tests.

Wasm Fuzzing Foundation This CL is the foundation of a new Part of the FuzzIL, a part that shows how we can leverage the powerful FuzzIL to lift into a different target language (i.e. Wasm) that is unified through Fuzzilli's powerful type system. This allows us to fuzz the full V8 engine from JS to Wasm and back again. We maintain the good properties of FuzzIL that lends itself to mutation based fuzzing and compile it down to Wasm. Fuzzilli can maintain strict typing that is necessary in Wasm while being flexible enough to do powerful mutations in the JS parts.

2025-01-07

Give functions names This change introduces a new intermediate FuzzIL operation class: BeginAnyNamedFunction. This class has an optional functionName string and is used for plain, generator, async, and async generator functions. During lifting, if the functionName is present, it will be used as the function's identifier instead of an automatically assigned name (something like `f23`). This now makes it possible to correctly compile function definitions. In particular, it makes it possible to support test cases that rely on function hoisting as the function's name is important for that to work. In general, we still prefer function with "dynamic" names (where the lifter assigns a unique identifier during lifting) to avoid name collisions during mutations (e.g. because we're splicing a function with the same name as an existing function into a program). As such, this change also modifies the minimizer to try and remove function names if they are not important for the behavior of the program. Change-Id: Ia6169d4440c7de3a77c38f71edfc2a728456076d Reviewed-on: https://chrome-internal-review.googlesource.com/c/v8/fuzzilli/+/7934267 Commit-Queue: Samuel Groß <saelo@google.com> Reviewed-by: Carl Smith <cffsmith@google.com>

Redesign strict mode Instead of a boolean flag on every function definition, we now have an explicit `Directive` FuzzIL operation which can be used to emit "use strict" and similar directives. Implementing it this way has a number of benefits: 1. It's more flexible, allowing the mutator to move the "use strict" directives elsewhere in the program to see if that triggers interesting behavior 2. It's easier to minimize: previously we needed special logic to turn strict mode functions into normal ones. Now this happens automatically when the Directive operation is removed. 3. It allows proper compilation of functions in strict mode. Change-Id: Iaef8bb95ad4cb64fef03f95c5b8fc4bf5288f30b Reviewed-on: https://chrome-internal-review.googlesource.com/c/v8/fuzzilli/+/7934266 Commit-Queue: Samuel Groß <saelo@google.com> Reviewed-by: Carl Smith <cffsmith@google.com>

2025-01-06

Redesign named variables in FuzzIL This change replaces the three operations LoadNamedVariable, StoreNamedVariable, and DefineNamedVariable with a single new operation: CreateNamedVariable. This operation now simply creates a new FuzzIL variable that will be assigned a specific identifier during lifting. Optionally, the named variable can be declared using any of the available variable declaration modes: global, var, let, or const. Below is a small example of how CreateNamedVariable can be used: // Make an existing named variable (e.g. a builtin) available v0 <- CreateNamedVariable 'print', declarationMode: .none // Overwrite an existing named variable v1 <- CreateNamedVariable 'foo', declarationMode: .none v2 <- CallFunction v0, v1 v3 <- LoadString 'bar' Reassign v1, v3 // Declare a new named variable v4 <- CreateNamedVariable 'baz', declarationMode: .var, v1 v5 <- LoadString 'bla' Update v4 '+' v5 v5 <- CallFunction v0, v4 This will lift to JavaScript code similar to the following: print(foo); foo = "bar"; var baz = foo; baz += "bla"; print(baz); With this, we now have a single, flexible way of creating variables that have a specific name. We now use this: * For builtins, which are effectively just existing named variables in the global scope. This also now makes it (easily) possible to overwrite builtins. As such, The LoadBuiltin operation was removed. * During code generation, to sometimes create variables with specific names in generated code (we use random property names). * In the compiler. This is the main user of named variables and this is where this change has the most impact: we now compiler _every_ variable declaration to a CreateNamedVariable operation. This now makes it possible to correctly compiler any code that relies on variable names, for example due to using `eval`, with statements, or similar constructs. See some of the added/modified tests for examples. The consequence of this is that compiled code will now often have a lot of CreateNamedVariable operations. However, as these are now just regular FuzzIL variables, this change should not significantly affect the mutability of the programs. Furthermore, the CreateNamedVariable can be removed during minimization if they are not needed. Change-Id: Ide0589e1492c8e70fe6da174b7983d2d3d760ba3 Reviewed-on: https://chrome-internal-review.googlesource.com/c/v8/fuzzilli/+/7934186 Commit-Queue: Samuel Groß <saelo@google.com> Reviewed-by: Carl Smith <cffsmith@google.com>

2024-12-05

Add support for explicit resource management proposal This CL adds support to generate tests for new `using` and `await using` syntax in Fuzzilli. It also adds the dispose and asyncDispose symbols.

2024-12-04

Update the compiler for void feature according to the new changes

feature/void

2024-11-21

Feature/super expression (#468) The enabled JSOperations are: CallSuperConstructor, SetSuperProperty, GetSuperProperty, SetComputedSuperProperty, GetComputedSuperProperty, CallSuperMethod, UpdateSuperProperty

2024-11-18

Feature/await expression (#469) * Implements compilation of the await expression * Implements basic test to ensure that await is covered in CompilerTests

2024-08-22

Minor fixes Remove noisy logging of the MinimizationPostProcessor. Make some tests that have expected log messages silent. Fix redeclaration of macro in libreprl-posix. Fix bug in gen_programproto.py.

Feature/switch statement js compiler (#440) * Implements JS->FuzzIL translatability for switch statements * Implements compiler tests for the switch statement * Improves Compiler and JS Parser

2024-07-30

Feature/with statement js compiler (#439) * Implements the step JS->FuzzIL for the With-Statement * Implements two unit tests for the With-Statement

2024-07-26

Feature/ternary expression js compiler (#438) * Makes conditional expressions compilable from JS to FuzzIL * Implements unit test for tertiary expression compilation

2023-11-21

Add ComputedSuperProperty instructions Fuzzilli is now able to emit computed super property accesses. E.g.: super[foo()] = 42; or: let baz = super[bar()];

2023-10-16

Make single explore operations deterministic. Add a JS RNG such that we can seed explore operations. If Fuzzilli is unable to convert explore operations into concrete operations when trying to reproduce a crash, the explore code itself might be important. In such cases we still want this explore operation to behave the same way it did when we observed the crash.

2023-08-08

Implement LoadNewTarget IL operation Implement the LoadNewTarget IL construct which allows loads of 'new.target' as well as a CodeGenerator that will emit LoadNewTarget. Also add a script to generate the program.proto file based on the Sources/Fuzzilli/FuzzIL/Opcodes.swift file.

2023-06-12

Track minimization overhead With this change, we now compute a "minimization overhead" for our statistics which represents the fraction of (recent) executions spent on minimization. For that, we add a |purpose| field to every execution which describes why we're executing a program. For the statistics we now only use the .minimization purpose, but if we want to, we could extend this in the future to get a detailed breakdown of exactly what our executions are spent on.

2023-06-06

Introduce FixupMutator This runtime-assisted mutator can "fix" existing instructions in a FuzzIL program. Fixing can for example mean: * Converting a guarded operation (i.e. one guarded by try-catch) into an unguarded one if it doesn't raise a runtime exception. * Changing the property/element accessed by e.g. a GetProperty operation if the the original property doesn't exist. * Changing the method or function/constructor if the original values are not callable. * Changing the inputs of arithmetic operations that previously produced NaN values (i.e. probably performed a "meaningless" operation). For now only the first feature (removal of unneeded guards) is implemented. The others will be added in the future. Until the other features are also implemented, the FixupMutator isn't enabled in the MutationEngine. However, instead it is used by the HybridEngine directly after code generation to remove unneeded guards. This design simplifies the code generation algorithm: whenever we cannot statically prove that an operation will not raise an exception, we can simply emit guards, then remove all unnecessary guards during a single, subsequent fixup mutation to produce the final output program.

2023-04-11

Introduce GuardableOperation A GuardableOperation is one that can be guarded against runtime exceptions caused by it. If guarding is active, any exception raised will be suppressed and following code will execute normally. When lifting to JavaScript, guarding is usually implemented by wrapping the code in a try-catch, but special handling is also possible. For example, guarded property loads use optional chaining: `o?.a` instead. This can now be used by CodeGenerators if they aren't sure that the operation will not cause a runtime exception. For example, the function call generator now looks like this: let arguments = b.randomArguments(forCalling: f) let needGuard = b.type(of: f).MayNotBe(.function()) b.callFunction(f, withArgs: arguments, guard: needGuard) Similarly, the method call generator will use guarding if it isn't sure that the method exists. In the future, various other operations could be guarded, such as binary operations (if mixing bigints and numbers), property stores (if the input may be nullish), or destruct operations (if the input isn't iterable). There are a few benefits to adding a language feature for guarding instead of, for example, creating explicit try-catch blocks: 1. both the generated code and the CodeGenerators become shorter. 2. it allows outputs of guarded instructions to be used as inputs for subsequent instructions as they remain in scope. 3. it makes it trivial to turn guarded operations into unguarded operations during minimization. 4. it makes it easy to implement runtime "fixing" of guarded operations to determine if the guard is needed, and remove it if it isn't.

2023-03-20

Implement support for computed methods in object literals

2023-03-18

Implement support for optional chaining This is based on pull request #322 We now have a `isGuarded` flag in various property-related operations (GetXYZ, DeleteXYZ, and CallXYZMethod) which, if enabled, causes the lifter to use the `?.` (and equivalent) operators instead of `.`. This makes the property access guarded in the sense that it will not cause a runtime exception if the access object is "nullish" (undefined or null).

2023-03-15

Add basic support for JavaScript classes to FuzzIL compiler

2023-03-14

Add support for TemplateLiterals to the FuzzIL Compiler

Implement LoopReducer This new reducer attempts to simplify and speed-up loops: - Complex loops are replaced with simple repeat-loops - Nested loops are replaced with a single loop - Loops with many iterations are replaced with loops with fewer iterations This should reduce the number of timeouts due to trivial infinite loops (because repeat-loops cannot be mutated into infinite loops) and should generally speed up the programs due to reduced loop iteration counts.

2023-03-11

Redesign For-Loops in FuzzIL Similar to while- and do-while loops, for-loops now consists of multiple blocks: BeginForLoopInitializer // ... // v0 = initial value of the (single) loop variable BeginForLoopCondition v0 -> v1 // v1 = current value of the (single) loop variable // ... BeginForLoopAfterthought -> v2 // v2 = current value of the (single) loop variable // ... BeginForLoopBody -> v3 // v3 = current value of the (single) loop variable // ... EndForLoop A simple for-loop will be lifted to: for (let i = init; cond; afterthought) { body(i); } However, more (and less) complex for loops are also possible. Some examples include: for (;;) { body(); } for (let i4 = f1(), i5 = f2(); f3(i4), f4(i5); f5(i5), f6(i4)) { body(i4, i5); } for (let [i6, i7] = (() => { const v1 = f(); const v3 = g(); h(); return [v1, v3]; })(); i6 < i7; i6 += 2) { body(i6, i7); } See the added tests for yet more examples.

2023-03-09

Refactor while- and do-while loops in FuzzIL These loops now have the following general shape: BeginLoopHeader // header code BeginLoopBody // body code EndLoop This now allows arbitrary computations to be performed in loop headers, as is also possible in JavaScript. It also allows us to compile all possible while- and do-while loops from JavaScript to FuzzIL, not just those that have a particular shape (e.g. have a single comparison, which was previously required). In JavaScript, a loop header must consist of exactly one expression. However, this is purely a syntactical restriction. If the FuzzIL loop header consists of multiple expressions, these are simply chained together using the comma operator: while (foo(), bar(), baz()) { ... } Further, if the FuzzIL loop header contains more complicated code such as control-flow, the header is lifted to an arrow function: while ((() => { if (x) { return y; } return z; })()) { ... }

2023-02-27

Also track (current) average execution time in Statistics

2023-02-22

Add a basic JavaScript-to-FuzzIL compiler The new compiler: - Is (mostly) written in Swift to ensure that changes to FuzzIL are reflected in the compiler. - Features an "end-to-end" testsuite that runs as part of `swift test`. The testsuite consists of a number of JavaScript programs which are compiled to FuzzIL, then lifted back to JavaScript and checked to produce the same output as the original code. - Uses a (fairly) stable protobuf-based AST format which is currently produced by a node.js-based parser (since there seem to be no good JavaScript parsers with swift integration), but could also be produced by any other parser. The compiler is still quite far away from being feature complete but it should support the most important language features. Adding support for more features is usually relatively simple: typically it involves adding one or more tests to the testuite, adding the relevant AST nodes to ast.proto, updating the parser script to emit these nodes, and updating the compiler to handle them. However, some features may require changes to FuzzIL, such as proper handling of loop headers. The compiler is currently exposed through the FuzzILTool's --compile option. In the future we may want to have a more sophisticated CLI interface, for example to allow removing calls to certain functions (such as assertX from tests) from the compiled code.

2023-02-21

Refactor the instance synchronization protocol The high-level protocol is now implemented in a single place: Sync.swift, while the concrete implementations for synchronizing instances over a network or between threads now only need to take care of delivering the message to the other end. This makes the communication more robust as the same messages are sent between instances no matter how they are connected. Moreover, this commit also refactors the corpus import mechanism, which is now performed in small steps instead of as one large operation, making the fuzzer responsive (UI, network, ...) during a corpus import.

2023-02-02

Implement Named Variables This commit adds three new FuzzIL operations: v3 <- LoadNamedVariable 'foo' StoreNamedVariable 'bar' <- v1 DefineNamedVariable 'baz' <- v2 These are lifted, respectively, to: const v3 = foo; bar = v1; var baz = v2; This now makes a few things possible: - The use of the 'var' keyword - Triggerring variable hoisting (if a LoadNamedVariable happens before a DefineNamedVariable) - Use of global variables (if a named variable is loaded/stored but never defined) - Access to object properties inside a `with` statement (this previously required LoadFromScope/StoreToScope, which are now gone)

2023-01-31

Refactor the Environment protocol This commit changes two things: 1) It refactors the sets of property and method names exposed by the environment. Now there are simply four sets: customProperties and customMethods, wich are properties/methods that should be used when defining properties/methods on objects, and builtinProperties and builtinMethods which are properties/methods that exist on builtin objects. When adding new properties/methods to an object we now always select the name from the customProperties/Methods sets. Furthermore, when not having static type information, we now also prefer to pick a random method from the customProperties/Methods set as there will be a higher chance of success. 2) It removes some properties from builtin objects in the environment model. Basically, we now only want to model properties/methods that are unique to one object type (e.g. "byteLength"), and not those that are common to many different object types (e.g. "constructor"). Otherwise, for example for Arrays we'd have a 50/50 chance of picking "length" (probably relevant) or "constructor" (probably less relevant). For common properties that should still be accessed, e.g. "__proto__" we rely on CodeGenerators or the ExplorationMutator.

2023-01-19

Rename some FuzzIL operations In essence, what used to be called StoreSomethingWithBinop is now simply called UpdateSomething. Further, the LoadSomething and StoreSomething operations for object fields (e.g. LoadProperty, StoreElement, ...) have been renamed to GetSomething and SetSomething.

Add support for private class fields

2023-01-18

Add support for class static initializers

Add support for class (instance and static) getters and setters

Add support for class static methods

2023-01-17

Add support for class static properties, elements, and computed properties

2023-01-16

Add support for class instance elements and computed properties

Refactor class definitions in FuzzIL They are now modelled similar to object literals: v0 <- BeginClassDefinition [optional superclass] ClassAddInstanceProperty ClassAddInstanceElement ClassAddInstanceComputedProperty BeginClassConstructor -> v1, v2 // v1 is the |this| object ... EndClassConstructor BeginClassInstanceMethod -> v6, v7, v8 // v6 is the |this| object ... EndClassInstanceMethod BeginClassInstanceGetter -> v12 // v12 is the |this| object ... EndClassInstanceGetter BeginClassInstanceSetter -> v18, v19 // v18 is |this|, v19 the new value ... EndClassInstanceSetter ClassAddStaticProperty ClassAddStaticElement ClassAddStaticComputedProperty BeginClassStaticMethod -> v24, v25 ... EndClassStaticMethod BeginClassStaticInitializer EndClassStaticInitializer EndClassDefinition This commit only adds support for instance properties and methods. Support for other types of fields will be added in a subsequent commit.

2023-01-11

Refactor random value generation in ProgramBuilder This commit removes the seenXYZ sets for int/float/string values previously seen by this builder. It is not clear that these provide any net benefits: on the one hand, they may cause e.g. a property that was previous set to later be read again but on the other hand they may cause e.g. the same property or element to be defined multiple times, or the same integer/float value to be used for multiple computations. As an alternative, this commit now refines methods such as randIndex() to return values from a smaller range more frequently so as for example to increase the chance of the same element being accessed. Futhermore, mutators such as the Exploration- or ProbingMutator also help to ensure that existing properties are accessed or non-existant (but accessed) properties installed.

2023-01-09

Improve object literals Object literals are now significantly more powerful and support: - Plain properties - Elements - Computed properties - Spread operations - Methods - Getters - Setters This is implemented using a new ObjectLiteral block type in FuzzIL: BeginObjectLiteral ObjectLiteralAddProperty 'foo', v42 ObjectLiteralAddElement '0', v43 ObjectLiteralAddComputedProperty v44, v45 ObjectLiteralCopyProperties v46 BeginObjectLiteralMethod 'bar' -> v47 ... EndObjectLiteralMethod BeginObjectLiteralGetter 'baz' -> v48 ... EndObjectLiteralGetter BeginObjectLiteralSetter 'baz' -> v49, v50 ... EndObjectLiteralSetter v51 <- EndObjectLiteral Note that the output is only defined by the EndObjectLiteral operation as the output itself is not available as an input inside the literal.

2023-01-04

Introduce CreateIntArray and CreateFloatArray Operations Currently, creating a JS Array with multiple, different integer or float values would require first loading all initial values into local variables using LoadInt/LoadFloat, then using CreateArray to turn them into a JS Array. This is, however, fairly inefficient: afterwards, there will be n local variables containing the element values and only one value containing the array itself, so the probability of the array being subsequently used is fairly low. With this change, the new operations now directly contain their values as Swift array and so do not require any additional FuzzIL variables.

2022-12-29

Rename ConditionalOperation to TernaryOperation Which is more in line with the other UnaryOperation and BinaryOperation.

2022-11-08

Implement the ProbingMutator Quoting from the documentation: This mutator inserts probes into a program to determine how existing variables are used. Its main purpose is to determine which (non-existent) properties are accessed on existing objects and to then add these properties (or install accessors for them). This mutator achieves this by doing the following: 1. It instruments the given program by inserting special Probe operations which turn an existing variable into a "probe" that records accesses to non-existent properties on the original value. In JavaScript, probing is implemented by replacing an object's prototype with a Proxy around the original prototype. This Proxy will then see all accesses to non-existent properties. Alternatively, the probed object itself could be replaced with a Proxy, however that will cause various builtin methods to fail because they for example expect |this| to have a specific type. 2. It executes the instrumented program. The program collects the property names of non-existent properties that were accessed on a probe and reports this information to Fuzzilli through the FUZZOUT channel at the end of the program's execution. 3. The mutator processes the output of step 2 and randomly selects properties to install (either as plain value or accessor). It then converts the Probe operations to an appropriate FuzzIL operation (e.g. StoreProperty).

2022-11-07

Allow If blocks without Else blocks

Add RepeatLoop to FuzzIL This is a loop that simply runs for a constant number of iterations without taking any input variables. This can be useful for example to force JIT compilation without having to create additional variables.

2022-10-27

Add BeginConstructor and EndConstructor Constructors are lifted to plain functions in JavaScript but they have an explicit |this| parameter and are typed as .constructor instead of .function by the typer.

2022-10-26

Implement Configure[Property|Element|ComputedProperty] operations These lift to Object.defineProperty calls and allow for better coverage of property/element accessors as well as property flags.

2022-10-14

More InliningReducer fixes and improvements When determining whether a function can be inlined, if a LoadArguments is seen, the function cannot be inlined. However, the LoadArguments may also belong to e.g. a BeginMethod, which needs to be handled. In the future, the handling of anything function-like should be unified by using the new BeginAnySubroutine Operation class. For now though, we need special handling until classes are refactored.

2022-10-13

Change handling of Switch Case blocks in FuzzIL Convert Switch Case blocks into their own blocks with their own context. Also implement a reducer to minimize Switch Case blocks.

2022-10-12

Remove FunctionSignature from FunctionDefinitions Instead, use a simpler Parameters struct which currently just stores the number of parameters and whether there is a rest parameter. It likely makes little sense to encode type information about parameters (such as "parameter 1 is a Uint8Array") in a function definition as there is no way to ensure that the information stays accurate (e.g. due to mutations). It's also generally not possible for a JavaScript -> FuzzIL compiler to determine type information for parameters. With this change, the implementation of types are again an implementation detail and no longer exposed in e.g. protobufs.

2022-10-05

Remove runtime type collection support This feature is essentially replaced by the ExplorationMutator which also uses runtime type information but instead of forwarding it to Fuzzilli (which then later on selects actions to perform based on the type), it directly selects a "useful" action to perform. This is a lot simpler and easier to maintain as the complexity is contained in a single mutator instead of being spread throughout the codebase.

2022-10-03

Implement ExplorationMutator Quoting from the documentation: This mutator does the following: 1. it inserts Explore operations for random existing variables in the program to be mutated 2. It executes the resulting (temporary) program. The Explore operations will be lifted to a sequence of code that inspects the variable at runtime (using features like 'typeof' and 'Object.getOwnPropertyNames' in JavaScript) and selects a "useful" operation to perform on it (e.g. load a property, call a method, ...), then reports back what it did 3. the mutator processes the output of step 2 and replaces some of the Explore mutations with the concrete action that was selected at runtime. All other Explore operations are discarded. The result is a program that performs useful actions on some of the existing variables even without statically knowing their type. The resulting program is also deterministic and "JIT friendly" as it no longer relies on any kind of runtime object inspection.

2022-08-03

Make operation names and ProgramBuilder methods more consistent Now, for a simple operation OperationXYZ, the ProgramBuilder will generally have a method opXYZ(...), while for block operations BeginBlockXYZ and EndBlockXYZ, it will have a buildBlockXYZ(...) method with ensures that the begin and end operations always match.

2022-07-27

Compute correctness and timeout rate over last 1000 samples Now that we do initial corpus generation with a different fuzzing engine, these statistics are somewhat skewed, at least during early fuzzing. Computing them over the last 1000 samples mitigates that.

Split call/construct operations into plain and spreading variants Spreading operations are not very "mutation friendly" since spreading rarely causes new interesting behaviour and will frequently cause invalid programs as only iterable objects can be spread. Therefore we now split up the CallFunction, Construct, CallMethod, and CallComputedMethod into "plain" versions and spreading versions which have the "WithSpread" suffix.

2022-07-26

Implement minimization and mutation of variadic instructions With this change, the Minimizer is now able to remove variadic inputs from instructions and the OperationMutations is able to add variadic inputs to them. To measure the impact of this, the average size of programs added to the corpus is now inlcluded in the statistics.

2022-02-15

Replace Types with Parameters in Function Signatures (#314)

2022-01-05

Add DestructObject and DestructObjectAndReassign operations (#309)

2022-01-04

simplify switch statement generation (#216)

2021-12-17

CallSuperConstructor now supports spread arguments (#302)

2021-12-16

Add array destruct support to ForOf (#303)

2021-11-21

Add DestructArray and DestructArrayAndReassign operations (#300)

2021-11-19

Add binary operation variants for StoreProperty, StoreElement, StoreComputedProperty and StoreSuperProperty (#296)