Added Showcase entries for JerryScript.

.gitignore

@@ -3,3 +3,7 @@ Package.resolved
 /.build
 /Packages
 /*.xcodeproj
+.vscode
+
+# custom GCE configuration
+Cloud/GCE/config.sh

Cloud/Docker/DuktapeBuilder/Dockerfile

@@ -24,4 +24,4 @@ RUN apt-get -y update && apt-get -y upgrade
 # Assume that the current master branch maintains duk-fuzzilli
 # No need to patch, as the fuzz target is maintained in the duktape repo
 # Start building!
-RUN make duk-fuzzilli
+RUN make build/duk-fuzzilli

Cloud/Docker/DuktapeBuilder/build.sh

@@ -11,12 +11,12 @@ REV=$(git ls-remote https://github.com/svaarala/duktape.git | grep refs/heads/ma
 # Since fuzzilli is integrated as a duktape make target, no need to pull over patches or a build script
 
 # Fetch the source code, get the current master commit, and compile the engine
-sudo docker build --build-arg rev=$REV -t duktape_builder .
+docker build --build-arg rev=$REV -t duktape_builder .
 
 # Copy build products
 mkdir -p out
-sudo docker create --name temp_container duktape_builder
-sudo docker cp temp_container:/home/builder/duktape/duk-fuzzilli out/duk-fuzzilli
-sudo docker rm temp_container
+docker create --name temp_container duktape_builder
+docker cp temp_container:/home/builder/duktape/build/duk-fuzzilli out/duk-fuzzilli
+docker rm temp_container
 
-# Nothing extra to clean up!
+# Nothing extra to clean up!

Cloud/Docker/FuzzilliBuilder/build.sh

@@ -12,13 +12,13 @@ cp -r $FUZZILLI_ROOT/Tests fuzzilli
 cp -r $FUZZILLI_ROOT/Package.swift fuzzilli
 
 # Compile Fuzzilli
-sudo docker build -t fuzzilli_builder .
+docker build -t fuzzilli_builder .
 
 # Copy build products
 mkdir -p out
-sudo docker create --name temp_container fuzzilli_builder
-sudo docker cp temp_container:/home/builder/fuzzilli/.build/release/FuzzilliCli out/Fuzzilli
-sudo docker rm temp_container
+docker create --name temp_container fuzzilli_builder
+docker cp temp_container:/home/builder/fuzzilli/.build/release/FuzzilliCli out/Fuzzilli
+docker rm temp_container
 
 # Clean up
 rm -rf fuzzilli

Cloud/Docker/JSCBuilder/build.sh

@@ -11,13 +11,13 @@ cp -R $FUZZILLI_ROOT/Targets/JavaScriptCore/Patches .
 cp $FUZZILLI_ROOT/Targets/JavaScriptCore/fuzzbuild.sh .
 
 # Fetch the source code, apply patches, and compile the engine
-sudo docker build --build-arg rev=$REV -t jsc_builder .
+docker build --build-arg rev=$REV -t jsc_builder .
 
 # Copy build products
 mkdir -p out
-sudo docker create --name temp_container jsc_builder
-sudo docker cp temp_container:/home/builder/webkit/FuzzBuild/Debug/bin/jsc out/jsc
-sudo docker rm temp_container
+docker create --name temp_container jsc_builder
+docker cp temp_container:/home/builder/webkit/FuzzBuild/Debug/bin/jsc out/jsc
+docker rm temp_container
 
 # Clean up
 rm -r Patches

Cloud/Docker/JerryScriptBuilder/build.sh

@@ -11,13 +11,13 @@ cp -R $FUZZILLI_ROOT/Targets/Jerryscript/Patches .
 cp $FUZZILLI_ROOT/Targets/Jerryscript/fuzzbuild.sh .
 
 # Fetch the source code, apply patches, and compile the engine
-sudo docker build --build-arg rev=$REV -t jerryscript_builder .
+docker build --build-arg rev=$REV -t jerryscript_builder .
 
 # Copy build products
 mkdir -p out
-sudo docker create --name temp_container jerryscript_builder
-sudo docker cp temp_container:/home/builder/jerryscript/build/bin/jerry out/jerry
-sudo docker rm temp_container
+docker create --name temp_container jerryscript_builder
+docker cp temp_container:/home/builder/jerryscript/build/bin/jerry out/jerry
+docker rm temp_container
 
 # Clean up
 rm -r Patches

Cloud/Docker/README.md

@@ -16,6 +16,8 @@ The container image will *not* contain any temporary build artifacts, source cod
 1. Make sure docker is installed
 2. Run `./build.sh [jsc|spidermonkey|v8|duktape|jerryscript|all]`
 
+The build script might have to run as root, depending on how [docker is configured](https://docs.docker.com/engine/install/linux-postinstall/#manage-docker-as-a-non-root-user).
+
 Afterwards, a docker image named "fuzzilli" will be available and can be used to fuzz any of the compiled JS engines (in this example JavaScriptCore) with Fuzzilli: `docker run -ti fuzzilli ./Fuzzilli --profile=jsc ./jsc/jsc`
 
 It is also possible to only rebuild Fuzzilli and use previously compiled engines by running `./build.sh fuzzilli`

Cloud/Docker/SpidermonkeyBuilder/build.sh

@@ -11,13 +11,13 @@ cp -R $FUZZILLI_ROOT/Targets/Spidermonkey/Patches .
 cp $FUZZILLI_ROOT/Targets/Spidermonkey/fuzzbuild.sh .
 
 # Fetch the source code, apply patches, and compile the engine
-sudo docker build --build-arg rev=$REV -t spidermonkey_builder .
+docker build --build-arg rev=$REV -t spidermonkey_builder .
 
 # Copy build products
 mkdir -p out
-sudo docker create --name temp_container spidermonkey_builder
-sudo docker cp temp_container:/home/builder/firefox/js/src/fuzzbuild_OPT.OBJ/dist/bin/js out/js
-sudo docker rm temp_container
+docker create --name temp_container spidermonkey_builder
+docker cp temp_container:/home/builder/firefox/js/src/fuzzbuild_OPT.OBJ/dist/bin/js out/js
+docker rm temp_container
 
 # Clean up
 rm -r Patches

Cloud/Docker/V8Builder/build.sh

@@ -11,15 +11,15 @@ cp -R $FUZZILLI_ROOT/Targets/V8/Patches .
 cp $FUZZILLI_ROOT/Targets/V8/fuzzbuild.sh .
 
 # Fetch the source code, apply patches, and compile the engine
-sudo docker build --build-arg rev=$REV -t v8_builder .
+docker build --build-arg rev=$REV -t v8_builder .
 
 # Copy build products
 mkdir -p out
-sudo docker create --name temp_container v8_builder
-sudo docker cp temp_container:/home/builder/v8/v8/out/fuzzbuild/d8 out/d8
-sudo docker cp temp_container:/home/builder/v8/v8/out/fuzzbuild/snapshot_blob.bin out/snapshot_blob.bin
-sudo docker cp temp_container:/home/builder/v8/v8/out/fuzzbuild/icudtl.dat out/icudtl.dat
-sudo docker rm temp_container
+docker create --name temp_container v8_builder
+docker cp temp_container:/home/builder/v8/v8/out/fuzzbuild/d8 out/d8
+docker cp temp_container:/home/builder/v8/v8/out/fuzzbuild/snapshot_blob.bin out/snapshot_blob.bin
+docker cp temp_container:/home/builder/v8/v8/out/fuzzbuild/icudtl.dat out/icudtl.dat
+docker rm temp_container
 
 # Clean up
 rm -r Patches

Cloud/Docker/build.sh

@@ -96,4 +96,4 @@ fi
 # Build the final container image which only contains the binaries (no intermediate build artifacts, source code, etc.).
 #
 echo "[*] Packing Fuzzilli container image"
-sudo docker build -t $CONTAINER_NAME .
+docker build -t $CONTAINER_NAME .

Cloud/GCE/README.md

@@ -32,13 +32,15 @@ If the workload ever becomes too large for a network master instance, further le
 
 ## Quickstart
 
-1. [Create a GCP project](https://cloud.google.com/resource-manager/docs/creating-managing-projects) and optionally request quota increases (e.g. increase the maximum number of GCE instances)
-2. [Enable Private Google Access](https://cloud.google.com/vpc/docs/configure-private-google-access#configuring_access_to_google_services_from_internal_ips) for the default subnet in the [active region](https://cloud.google.com/compute/docs/regions-zones) (see [config.sh](./config.sh)) in the new project. This is necessary so that worker instances without a public IP address can access the project's docker registry
-3. Install and configure the [Google Cloud SDK](https://cloud.google.com/sdk)
-4. Edit [config.sh](./config.sh): insert the GCP Project ID and Number and potentially modify other configuration options as well
-5. Build the fuzzilli docker container. See [Docker/](../Docker)
-6. Push it to GCE: `./push.sh`
-7. Start fuzzing! `./start.sh all` :)
+1. [Create a GCP project](https://cloud.google.com/resource-manager/docs/creating-managing-projects)
+2. [Install](https://cloud.google.com/sdk/install) and [configure](https://cloud.google.com/sdk/docs/initializing) the [Google Cloud SDK](https://cloud.google.com/sdk)
+3. Create config based on [config-template.sh](./config-template.sh): `cp config-template.sh config.sh` and insert the GCP Project ID and Number and potentially modify other configuration options, such as the [GCE region](https://cloud.google.com/compute/docs/regions-zones), as well
+4. [Enable Private Google Access](https://cloud.google.com/vpc/docs/configure-private-google-access#configuring_access_to_google_services_from_internal_ips) for the default subnet in the selected region. This is necessary so that worker instances without a public IP address can access the project's docker registry
+5. [Enable the Container Registry API](https://cloud.google.com/container-registry/docs/quickstart) and [configure docker for access to the GCE docker registry](https://cloud.google.com/container-registry/docs/quickstart#add_the_image_to)
+6. Optionally [request a quota increase](https://cloud.google.com/compute/quotas) for the number of CPUS in the selected region. The default is 72
+7. Build the fuzzilli docker container. See [Docker/](../Docker)
+8. Push it to GCE: `./push.sh`
+9. Start fuzzing! `./start.sh all` :)
 
 To stop fuzzing, simply run `./stop.sh all`, but be sure to fetch all crashes first!
 

Cloud/GCE/config.sh → Cloud/GCE/config-template.sh

@@ -14,7 +14,7 @@ PROJECT_NUMBER=YOUR_PROJECT_NUMBER
 SESSION="fuzzilli"
 
 # The path to the JavaScript engine binary in the container
-BINARY=./d8
+BINARY=./v8/d8
 # Common arguments to pass to every Fuzzilli instance. See ./Fuzzilli --help
 FUZZILLI_ARGS="--profile=v8"
 
@@ -25,10 +25,11 @@ ZONE=$REGION-b
 # By default, the default service account: https://cloud.google.com/iam/docs/service-accounts#default
 SERVICE_ACCOUNT=$PROJECT_NUMBER-compute@developer.gserviceaccount.com
 
-# The machine image and docker container to use.
-IMAGE=cos-stable-81-12871-103-0
+# The docker container and OS image to use.
 CONTAINER_NAME=fuzzilli
 CONTAINER_IMAGE=gcr.io/$PROJECT_ID/$CONTAINER_NAME:latest
+# By default, use the latest stable OS image
+OS_IMAGE=$(gcloud compute images list --filter="family=cos-stable" --format="value(NAME)")
 
 # Number of master instances (N)
 NUM_MASTERS=8

Cloud/GCE/push.sh

@@ -7,5 +7,5 @@ set -e
 
 source config.sh
 
-sudo docker tag fuzzilli gcr.io/$PROJECT_ID/$CONTAINER_NAME
-sudo docker push gcr.io/$PROJECT_ID/$CONTAINER_NAME
+docker tag fuzzilli gcr.io/$PROJECT_ID/$CONTAINER_NAME
+docker push gcr.io/$PROJECT_ID/$CONTAINER_NAME

Cloud/GCE/start.sh

@@ -60,7 +60,7 @@ if [ "$START_ROOT" = true ]; then
         --maintenance-policy=MIGRATE \
         --service-account=$SERVICE_ACCOUNT \
         --scopes=https://www.googleapis.com/auth/devstorage.read_only,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/trace.append \
-        --image=$IMAGE \
+        --image=$OS_IMAGE \
         --image-project=cos-cloud \
         --boot-disk-size=10GB \
         --boot-disk-type=pd-ssd \
@@ -99,7 +99,7 @@ if [ "$START_MASTERS" = true ]; then
         --maintenance-policy=MIGRATE \
         --service-account=$SERVICE_ACCOUNT \
         --scopes=https://www.googleapis.com/auth/devstorage.read_only,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/trace.append \
-        --image=$IMAGE \
+        --image=$OS_IMAGE \
         --image-project=cos-cloud \
         --boot-disk-size=10GB \
         --boot-disk-type=pd-ssd \
@@ -147,7 +147,7 @@ if [ "$START_WORKERS" = true ]; then
             --preemptible \
             --service-account=$SERVICE_ACCOUNT \
             --scopes=https://www.googleapis.com/auth/devstorage.read_only,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/trace.append \
-            --image=$IMAGE \
+            --image=$OS_IMAGE \
             --image-project=cos-cloud \
             --boot-disk-size=10GB \
             --boot-disk-type=pd-ssd \

Docs/ProcessingModel.md

@@ -1,42 +1,40 @@
 # Processing Model
 
-Fuzzilli's processing and threading model is fairly simple: one Fuzzer instance has an associated
-sequential [OperationQueue](https://developer.apple.com/documentation/foundation/operationqueue) on
-which all interactions with the fuzzer must happen. The OperationQueue basically behaves like a
-serial [DispathQueue](https://developer.apple.com/documentation/dispatch/dispatchqueue) but allows a
-bit more control, e.g. setting a priority on an operation. This architecture avoids race conditions
-as all actions happen sequentially on the queue. It also makes it rather straight forward to run
-multiple Fuzzer instances in one process.
+Fuzzilli's processing and threading model is fairly simple: every Fuzzer
+instance has an associated sequential
+[DispatchQueue](https://developer.apple.com/documentation/dispatch/dispatchqueue)
+on which all interactions with the fuzzer must happen. This architecture avoids
+race conditions as work items are processed sequentially. It also makes it
+rather straight forward to run multiple Fuzzer instances in one process.
+Whenever code wants to interact with a fuzzer instance (i.e. call methods on
+it, access properties, etc.) but (potentially) executes on a different
+DispatchQueue, it has to first enqueue an operation into the Fuzzer's queue.
+For that, the Fuzzer class exposes the `sync` and `async` functions which
+essentially just enqueue the given work item into the fuzzer's DispatchQueue
+and which can safely be called from a separate thread:
 
-Essentially, in any code that is interacting with a Fuzzer instance the following assertion thus has
-to hold: `assert(OperationQueue.current == fuzzer.queue)`. This assertion is actually in place in a
-few central APIs in Fuzzilli to verify everything runs as expected. Whenever code wants to interact
-with a fuzzer instance (i.e. call methods on it, access properties, etc.) but (potentially) executes
-on a different OperationQueue/DispatchQueue than the instance's, it has to first enqueue an
-operation into the Fuzzer's queue:
-
-    fuzzer.queue.addOperation {        
+    fuzzer.async {
         // Can now interact with the fuzzer        
         fuzzer.importProgram(someProgram)
     }
 
-Any code that is invoked by Fuzzilli (e.g. Mutators, Module initializers, CodeGenerators, Event and
-Timer handlers, etc.) will always execute on the fuzzer's operation queue and thus does not need to
-worry about enqueuing tasks first. Only if code uses further DispatchQueues, threads, etc. must it
-ensure that it only interacts with the fuzzer on the correct queue. See e.g. the ThreadSync module
-for an example of this.
+Any code that is invoked by Fuzzilli (e.g. Mutators, Module initializers,
+CodeGenerators, Event and Timer handlers, etc.) will always execute on the
+fuzzer's dispatch queue and thus does not need to worry about enqueuing tasks
+first. Only if code uses separate DispatchQueues, threads, etc. must it ensure
+that it always interacts with the fuzzer on the correct queue. See e.g. the
+ThreadSync or NetworkSync module for examples of this.
 
-The operation queue of a typical fuzzer commonly contains (some of) the following items:
+The dispatch queue of a typical Fuzzer instance commonly contains (some of) the
+following items:
 
-* A call to Fuzzer.fuzzOne to perform the next round of fuzzing. This operation is enqueued with  
-  lowest priority so actual fuzzing is only performed when there is nothing else (e.g. worker  
-  synchronization) to do. When fuzzOne finishes one round of fuzzing it will enqueue the next  
-  fuzzOne operation. As such there will always be a fuzzOne operation queued
-* Handler blocks for any timers scheduled via the Fuzzer.timers API that have recently triggered
-* Event handlers for asynchronously dispatched events (See Events.swift). Synchronously dispatched  
-  events on the other hand execute directly in the context of the code that dispatches the event,  
-  which must, of course, also execute on the fuzzer's operation queue
-* Handlers for incoming network connections and data if the NetworkSync module is active
-* Handlers for messages from other fuzzers in the network if any of the synchronization modules is  
-  active
-* ...
+* A call to Fuzzer.fuzzOne to perform one iteration of fuzzing. When fuzzOne
+  finishes, it will schedule the next fuzzing iteration.
+* Handler blocks for any timers scheduled via the Fuzzer.timers API that have
+  recently triggered
+* Handlers for incoming network connections and data if the NetworkSync module
+  is active
+* Handlers for messages from other fuzzers if any of the fuzzer synchronization
+  modules are active
+* Program executions scheduled by the minimizer (which runs on a separate queue
+  since it often takes a long time to complete)