AI prompts
base on Hermit launches linux x86_64 programs in a special, hermetically isolated sandbox to control their execution. Hermit translates normal, nondeterministic behavior, into deterministic, repeatable behavior. This can be used for various applications, including replay-debugging, reproducible artifacts, chaos mode concurrency testing and bug analysis. # Hermit: A reproducible container
Hermit forces deterministic execution of arbitrary programs and acts like a
reproducible container. That is, it _hermetically_ isolates the program from
sources of non-determinism such as time, thread interleavings, random number
generation, etc. Guaranteed determinism is a powerful tool and it serves as a
basis for a number of applications, including concurrency stress testing,
record/replay, reproducible builds, and automatic diagnosis of concurrency bugs,
and more.
Hermit cannot isolate the guest program from sources of non-determinism such as
file system changes or external network responses. Instead, in order to provide
complete determinism, the user should provide a fixed file system base image
(e.g., with Docker) and disable external networking.
> [!WARNING]
>
> Hermit is no longer under active development within Meta and is in maintenance
> mode. There is a long tail of unsupported system calls that may cause your
> program to fail while running under Hermit. Unfortunately, we (the team behind
> this project) don't have the resources to triage issues, fix major bugs, or
> add features at this point in time.
>
> If you are interested in this project and want to make contributions, please
> submit a pull request. We will prioritize merging these over anything else.
# How it works
Hermit sits between the guest process and the OS intercepting system calls made
by the guest (using [Reverie][]). In some cases, it can completely replace the
functionality of the kernel and suppress the original system call. In other
cases, it forwards the system call to the kernel and sanitizes the response such
that it is made deterministic.
As a concrete example, lets say we have a program that reads random bytes from
`/dev/urandom`. Hermit will see that the guest opened this file (a known source
of non-determinism) and intercept subsequent reads to this file. Instead of
letting the OS fill a buffer with random bytes, Hermit uses a deterministic
pseudorandom number generator with a fixed seed to fill in the buffer. The
contents of the buffer are then guaranteed to be the same upon every execution
of the program.
The most complex source of non-determinism is in the thread scheduler. The way
threads are scheduled by the kernel depends on many external factors, including
the number of physical CPUs or other threads running on the system that require
CPU time. To ensure that the threads of the guest process (and all of its child
processes) are scheduled in a repeatable way, we first make sure that all thread
executions are serialized so that there is effectively only one CPU. Then, we
deterministically pick which thread is allowed to run next. In order to only
allow a thread to run for a fixed number of instructions, we use the CPU's
Performance Monitoring Unit (PMU) to stop execution after a fixed number of
retired conditional branches (RCBs).
Read below about how to build Hermit, and you can get an idea of what it does
from running examples in the [./examples](./examples) folder.
[Reverie]: https://github.com/facebookexperimental/reverie
# Building and running Hermit
Hermit is built with the standard Rust cargo tool.
```bash
cargo build
```
This builds the whole cargo workspace. The actual binary is located in target
directory (`target/debug/hermit`).
Then, once you've built Hermit, all you need to run your program
deterministically is:
```bash
hermit run <prog>
```
After that you can try running it in a concurrency stress testing (chaos) mode,
or varying other parameters of the configuration such as the speed at which
virtual time passes inside the container, or the random number generation seed:
```bash
hermit run --chaos --sched-seed=3 <prog>
```
You can use hermit as a replay-debugger as well, either recording a
non-deterministic execution (real time, real randomness, etc), or repeatedly
running a controlled, deterministic one (virtual time, pseudo-randomness, etc).
```bash
hermit record start <prog>
hermit replay
```
# Example programs
See the [the examples folder](./examples/README.md) for example programs and
instructions on how to run them. These showcase different sources of
nondeterminism, and how hermit eliminates or controls them.
In order to explore more advanced examples, you can look at some of the
integration tests built from [./tests/](./tests/) or
[./flaky-tests/](./flaky-tests/). For example, using the commands below you can
run a racey example multiple times to see its nondeterminism. Then run it under
hermit to watch that nondeterminism disappear. Then run it under hermit
`--chaos` to bring that nondeterminism back, but in a controlled way that can be
reproduced based on the input seed.
```bash
cargo build
for ((i=0; i<20; i++)); do ./target/debug/hello_race; done
for ((i=0; i<20; i++)); do hermit run ./target/debug/hello_race; done
for ((i=0; i<20; i++)); do
hermit run --chaos --seed-from=SystemRandom ./target/debug/hello_race;
done
```
# The state of CI and testing
At Meta, this repository is built using buck. We have over 700 integration tests
that run under this setup. But as of this initial release (2022-11-21), we have
not ported these tests to an external build system yet.
A few unit tests run under `cargo test`, but the integration tests are more
complicated because they combine various run modes with each of the test
binaries (which are built from `tests/`, `flaky-tests/`, and the rr test suite
too).
We plan to get the internal Buck configuration files building externally with
buck or bazel.
# Applications
Hermit translates normal, non-deterministic Linux behavior, into deterministic,
repeatable behavior. This can be used for various applications, including:
record/replay debugging, simple reproducibility, "chaos mode" to expose
concurrency bugs in a controlled and repeatable way. Generally, Hermit makes
implicit inputs into explicit ones, and so enables searching over possible
executions by explicitly varying these inputs and study the changes in outcomes.
This can be used for either searching for bugs or trying to narrow down their
causes.
## Diagnosing concurrency bugs
One experimental application that Hermit has built-in support for is diagnosing
concurrency bugs, in terms of identifying the stack traces of racing critical
operations which, if their order is flipped in the schedule, cause the program
to crash (also called an "order violation" bug). Hermit can detect these even if
the racing instructions are in different processes and written in different
programming languages.
You can kick off analyze with any program invocation, and tell it to search for
failing (and passing) executions, and then diagnose the difference between them.
```
hermit analyze --search -- <run_args> <prog>
```
# License
Hermit is licensed under a BSD-3 clause license, included in the `LICENSE` file
in this directory.
# Support
Hermit currently supports x86_64 Linux. Aarch64 support is a work in progress.
", Assign "at most 3 tags" to the expected json: {"id":"9434","tags":[]} "only from the tags list I provide: [{"id":77,"name":"3d"},{"id":89,"name":"agent"},{"id":17,"name":"ai"},{"id":54,"name":"algorithm"},{"id":24,"name":"api"},{"id":44,"name":"authentication"},{"id":3,"name":"aws"},{"id":27,"name":"backend"},{"id":60,"name":"benchmark"},{"id":72,"name":"best-practices"},{"id":39,"name":"bitcoin"},{"id":37,"name":"blockchain"},{"id":1,"name":"blog"},{"id":45,"name":"bundler"},{"id":58,"name":"cache"},{"id":21,"name":"chat"},{"id":49,"name":"cicd"},{"id":4,"name":"cli"},{"id":64,"name":"cloud-native"},{"id":48,"name":"cms"},{"id":61,"name":"compiler"},{"id":68,"name":"containerization"},{"id":92,"name":"crm"},{"id":34,"name":"data"},{"id":47,"name":"database"},{"id":8,"name":"declarative-gui "},{"id":9,"name":"deploy-tool"},{"id":53,"name":"desktop-app"},{"id":6,"name":"dev-exp-lib"},{"id":59,"name":"dev-tool"},{"id":13,"name":"ecommerce"},{"id":26,"name":"editor"},{"id":66,"name":"emulator"},{"id":62,"name":"filesystem"},{"id":80,"name":"finance"},{"id":15,"name":"firmware"},{"id":73,"name":"for-fun"},{"id":2,"name":"framework"},{"id":11,"name":"frontend"},{"id":22,"name":"game"},{"id":81,"name":"game-engine "},{"id":23,"name":"graphql"},{"id":84,"name":"gui"},{"id":91,"name":"http"},{"id":5,"name":"http-client"},{"id":51,"name":"iac"},{"id":30,"name":"ide"},{"id":78,"name":"iot"},{"id":40,"name":"json"},{"id":83,"name":"julian"},{"id":38,"name":"k8s"},{"id":31,"name":"language"},{"id":10,"name":"learning-resource"},{"id":33,"name":"lib"},{"id":41,"name":"linter"},{"id":28,"name":"lms"},{"id":16,"name":"logging"},{"id":76,"name":"low-code"},{"id":90,"name":"message-queue"},{"id":42,"name":"mobile-app"},{"id":18,"name":"monitoring"},{"id":36,"name":"networking"},{"id":7,"name":"node-version"},{"id":55,"name":"nosql"},{"id":57,"name":"observability"},{"id":46,"name":"orm"},{"id":52,"name":"os"},{"id":14,"name":"parser"},{"id":74,"name":"react"},{"id":82,"name":"real-time"},{"id":56,"name":"robot"},{"id":65,"name":"runtime"},{"id":32,"name":"sdk"},{"id":71,"name":"search"},{"id":63,"name":"secrets"},{"id":25,"name":"security"},{"id":85,"name":"server"},{"id":86,"name":"serverless"},{"id":70,"name":"storage"},{"id":75,"name":"system-design"},{"id":79,"name":"terminal"},{"id":29,"name":"testing"},{"id":12,"name":"ui"},{"id":50,"name":"ux"},{"id":88,"name":"video"},{"id":20,"name":"web-app"},{"id":35,"name":"web-server"},{"id":43,"name":"webassembly"},{"id":69,"name":"workflow"},{"id":87,"name":"yaml"}]" returns me the "expected json"