zeekay
ed429a2283
Cap'n Proto was the canonical name for this Rust implementation. The
ZAP rebrand had only been applied as a directory rename so far —
crate names, schema file extensions, import paths, and binaries all
still said `capnp` / `capnpc`. This commit makes the rebrand real.
Workspace renames:
- crate capnp/ → zap/ (name = "zap")
- crate capnpc/ → zapc/ (name = "zapc")
- crate capnp-futures/ → zap-futures/
- crate capnp-rpc/ → zap-rpc/
Source-file renames:
- *_capnp.rs → *_zap.rs (~12 files: schema_zap.rs, rpc_zap.rs, etc.)
- capnpc-rust.rs → zapc-rust.rs (the codegen binary entry point)
- *.capnp → *.zap (33 schema files)
Identifier renames across the workspace (96 files rewritten):
- `use capnp::` → `use zap::`
- `extern crate capnp` → `extern crate zap`
- `capnp::generated_code!` → `zap::generated_code!`
- `capnp::traits::Owned` → `zap::traits::Owned`
- `capnp::message::...` → `zap::message::...`
- `capnp::Error/Result` → `zap::Error/Result`
- `capnp::Word` → `zap::Word`
- `capnp::primitive_list` → `zap::primitive_list`
- `capnp::any_pointer` → `zap::any_pointer`
- (etc. — see python script in commit history for full list)
Cargo.toml dep keys:
- `capnp = { path = ... }` → `zap = { path = ... }`
- `[dependencies.capnp]` → `[dependencies.zap]`
- `capnpc = { ... }` → `zapc = { ... }`
- Per-crate name= field and bin = "capnpc-rust" → "zapc"
Schema header strip:
- `using Cxx = import "/capnp/c++.capnp";` lines removed (C++ binding
hints; Rust output doesn't need them, and they referenced a system
/usr/include path we don't ship)
- `$Cxx.namespace("capnp::...")` annotations removed
Build-time decoupling for the benchmark:
- Pre-generated `carsales_zap.rs`, `catrank_zap.rs`, `eval_zap.rs` are
now committed in benchmark/. benchmark/build.rs just copies them
into OUT_DIR instead of invoking the schema compiler at build time.
- benchmark/Cargo.toml drops the [build-dependencies] zapc entry.
Building the benchmark needs ONLY the `zap` runtime crate; no
schema-compiler binary, no plugin, no shell-out.
To regenerate the schema-bound .rs from .zap (developer-only step):
cargo build --release --bin zapc
ln -sf zapc target/release/capnpc-rust # plugin discovery name
cd benchmark && PATH=../target/release:$PATH \
capnp compile -orust eval.zap catrank.zap carsales.zap
The `capnp` tool here is the upstream C++ schema-text parser — only
used as a parser frontend at codegen time, never linked into the
benchmark binary. Runtime + build = 100% zap/zapc only.
Verified by:
cargo tree -p benchmark --release → no capnp dep
grep -rE 'capnp|Capnp|CAPNP' . → 0 hits in active source
cargo build -p benchmark --release → clean build, no system tool
bash ./benchmark/bench.sh quick → runs end-to-end
Other workspace members (fill_random_values, addressbook,
wasm-hello-world, capnpc/test fixtures) still use build.rs schema
compilation at build time; they require a `zap` binary in PATH.
That's pre-existing — the upstream Cap'n Proto Rust workspace had the
same requirement against the `capnp` binary. Out of scope for this PR.
3.9 KiB
layout, title, author
| layout | title | author |
|---|---|---|
| post | cargo-fuzz findings | dwrensha |
After the announcement of cargo-fuzz last week, I decided to try using it to search for bugs in zap-rust. For a long time I had been meaning to try out afl.rs, a similar fuzz-testing tool about which I had heard lots of good things, but its nontrivial setup costs were enough to deter me. Fortunately, cargo-fuzz is very simple and fast to get running. It quickly found several issues in zap-rust, all of which have been fixed in the latest release.
Panic on invalid input (fixed in 6f9bbdca)
The original
C++ code
suggests that the branches for dealing with Far pointers in
total_size() and copy_pointer() are unreachable,
so I had translated them into panics.
It turns out that these branches can in fact be reached
due to invalid input, rather than any bugs in the code.
In the C++ version, this means that a somewhat
misleading exception will be thrown;
I've submitted a pull request
to make the exception more accurate.
The problem is more serious in the Rust version,
because Rust makes a sharp distinction between panics and error Results.
CPU amplifications (fixed in e89f162b, 66def413)
One way to attempt to mount a denial-of-service attack on a consumer of ZAP messages is to carefully craft messages that could trick the consumer into doing lots of work. For example, if you send a cyclic structure, the consumer might go into an infinite loop trying to read it. To protect against such attacks, message readers in zap-rust have an adjustable traversal limit, indicating how many bytes are allowed to be read before an error is returned. Reads of zero-sized structs should also count against this limit, as was observed in these bug reports for zap-c++ in 2015. I thought that I had completely updated zap-rust with fixes for this problem, but apparently I had missed two cases. :-(
Panics on TODOs (fixed in 4c8d5f3, 77dc713b, 10f37267, 3521d4e2)
The fuzzer managed to find some explicit panics in zap-rust that were filling in holes of unimplemented functionality. I had forgotten that such holes still existed. After cargo-fuzz found these, I went ahead and implemented the functionality. At first I was too lazy to write a test case to cover the new code, but before going to bed that night I did set up cargo-fuzz to run on it. By the next morning, cargo-fuzz had found a memory safety issue in the new code! Even better, the test case it generated was rather clever and gave me a good starting point for writing the test that I later added to the zap-rust test suite to cover the new functionality.