Skip to content
This repository has been archived by the owner on Nov 1, 2023. It is now read-only.

Latest commit

 

History

History
68 lines (53 loc) · 3.04 KB

containers.md

File metadata and controls

68 lines (53 loc) · 3.04 KB

Containers in OneFuzz

An Azure Blob Storage Container. Each fuzzing task has a set of required and potentially optional containers that are used in a specific context.

As an example, the libFuzzer fuzzing task uses the following:

  • setup: A container with the libFuzzer target executable and any prerequisites (shared objects, DLLs, config files, etc)
  • crashes: A container used to store any crashing input
  • inputs: A container of an initial corpus of seeding input for the libFuzzer target. Any newly discovered inputs are also saved to this container. All files saved in the inputs container are bidirectionally synced with the blob store.
  • readonly_inputs: An arbitrary set of additional input seed corpus containers. This container automatically pulls new files from the blob store, but nothing saved to these containers on the fuzzing VM is synced to the container.

Tasks can target a container for an input queue. As an example, the crash reporting tasks queue off of specified crashes containers, processing files iteratively from the queue.

Considerations on naming Containers

Users can create arbitrary containers (see Container Name Requirements), including the ability to set arbitrary metadata for a container.

Templates use containers built from the context it's being used (setup) and a namespaced GUID to enable automatic re-use of containers across multiple builds of the same target. NOTE: A helper utility is available to craft namespaced GUIDs onefuzz utils namespaced_guid.

As an example, setup and coverage containers are namespaced with the project, name, build, and platform (Linux or Windows). All other containers (inputs, crashes, reports, etc) use project and name.

Example:

The libfuzzer template with the project 'myproject', the name of 'mytarget', and build of build_1 on the Linux platform uses the following:

  • oft-setup-fd4addc373f3551caf780e80abaaa658
  • oft-coverage-fd4addc373f3551caf780e80abaaa658
  • oft-inputs-d532156b72765c21be5a29f73718af7e
  • oft-crashes-d532156b72765c21be5a29f73718af7e
  • oft-reports-d532156b72765c21be5a29f73718af7e
  • oft-unique-reports-d532156b72765c21be5a29f73718af7e
  • oft-no-repro-d532156b72765c21be5a29f73718af7e

The same target, but build_2 uses the following containers:

  • oft-setup-270ee492f18c5f71a0a3e1cffcb98f77
  • oft-coverage-270ee492f18c5f71a0a3e1cffcb98f77
  • oft-inputs-d532156b72765c21be5a29f73718af7e
  • oft-crashes-d532156b72765c21be5a29f73718af7e
  • oft-reports-d532156b72765c21be5a29f73718af7e
  • oft-unique-reports-d532156b72765c21be5a29f73718af7e
  • oft-no-repro-d532156b72765c21be5a29f73718af7e

The only difference is a unique oft-setup container.

In these examples, oft stands for OneFuzz Template "setup" container.