This is a correctness issue: When -fno-builtin is used, we must assume that we
could be compiling the memcpy/memset implementations, so generating calls to
them is problematic.
This can also be extended to ELF later as it means roughly the same thing there.
This addresses the main issue in #21721 but as I don't have a macOS machine to
do further testing on, I can't confirm whether zig cc is able to pass the entire
cgo test suite after this commit. It can, however, cross-compile a basic program
that uses cgo to x86_64-macos-none which previously failed due to lack of -x
support. Unlike previously, the resulting symbol table does not contain local
symbols (such as C static functions).
I believe this satisfies the related donor bounty: https://ziglang.org/news/second-donor-bounty
* Adds startTupleField/startStructField, makes pattern in print targets less verbose
* Makes some enums into strings
* Start/finish renamed to begin/end
I feel bad changing this, but I don't know why I named them this way in the first place.
Begin/end is consistent with the json API, and with other APIs in the wild that follow this pattern.
Better to change now than later.
When runtime safety is turned on, `Ed25519.fromSecretKey()` can
currently hit an assertion if the format of the secret key is
invalid.
Return an error instead, so that applications can recover.
Unfortunately some duplicate files must remain in lib/libc/wasi/libc-top-half
because they include internal headers *in the same directory* which have edits
relative to upstream musl. Because C is an amazing language, there is no way to
make it so that e.g. upstream musl's src/stdio/fputc.c includes wasi-libc's
src/stdio/putc.h instead of the upstream putc.h. The preprocessor always
searches the current directory first for quote includes.
Anyway, this still takes us from 2.9M to 1.4M for the combination of
lib/libc/wasi and lib/libc/include/wasm-wasi-musl, so I still call it a win.
`EACCES` is returned if the file mode bit (i.e., user/group/other rwx
bits) disallow access. `EPERM` is returned if something else denies
access (immutable bit, SELinux, capabilities, etc). This somewhat subtle
no-access distinction is part of POSIX. For now map both to
`error.PermissionDenied` to keep the error signature unchanged. See
duopoly.
This PR is effecitvely an update/simplification of PR #19193.
Tested locally with an immutable file.
Fixes#22733 and #19162.
- allow `-fsanitize-coverage-trace-pc-guard` to be used on its own without enabling the fuzzer.
(note that previouly, while the flag was only active when fuzzing, the fuzzer itself doesn't use it, and the code will not link as is.)
- add stub functions in the fuzzer to link with instrumented C code (previously fuzzed tests failed to link if they were calling into C):
while the zig compile unit uses a custom `EmitOptions.Coverage` with features disabled,
the C code is built calling into the clang driver with "-fsanitize=fuzzer-no-link" that automatically enables the default features.
(see de06978ebc/clang/lib/Driver/SanitizerArgs.cpp (L587))
- emit `-fsanitize-coverage=trace-pc-guard` instead of `-Xclang -fsanitize-coverage-trace-pc-guard` so that edge coverrage is enabled by clang driver. (previously, it was enabled only because the fuzzer was)
readAtLeast is greedy and will read the entire length of the buffer if it can. However, reading past the end of the cert in this case is useless, so reading the full length of the buffer just puts an increasingly large (due to the growth algorithm of ArrayList) collection of wasted bytes after each cert in cb.bytes.
In practical terms, this ends up saving potentially millions of bytes of wasted reads/allocations. In my testing, after reading the keychain files on my machine, cb.bytes ends up with these capacities:
- Before: cb.bytes.capacity = 32720747
- After: cb.bytes.capacity = 251937
That's a decrease of 99.2%
Additionally, swaps to readNoEof since it should be an error to hit EOF without reading the full cert size.
On my machine, the defaults are 5 seconds (LLDB) and 2 seconds (GDB). These are
too low on the CI machines during high load, and the CI system itself already
enforces a timeout on jobs anyway, so just disable the timeout altogether.
* std.crypto: add the ability to explicitly tag a value as secret
It turns out that Valgrind can be a very useful tool to check that secrets
are not leaked via side channels involving lookups or conditional jumps.
Valgrind tracks uninitialized data, and memcheck reports operations
involving uninitialized values. By permanently or temporarily telling
Valgrind that a memory region containing secrets is uninitialized, we can
detect common side-channel vulnerabilities.
For example, the following code snippets would immediately report that the
result is not computed in constant time:
```zig
classify(&key);
const len = std.mem.indexOfScalar(u8, &key, 0);
```
```zig
classify(&key);
const idx = key[0];
x += idx;
```
```zig
var x: [4]u8 = undefined;
std.crypto.random.bytes(&x);
classify(&x);
if (std.mem.eql(u8, "test", &x)) return;
```
This is not fool-proof, but it can help a lot to detect unwanted compiler
optimizations.
Also, right now, this is relying on Valgrind primitives, but these
annotations can be used to do more interesting things later, especially with
our own code generation backends.
* Update for Zig 0.14
* Remove checks for Valgrind enablement
Four tests in lib/std/posix/test.zig were disabled because they created
fixed-name files in the current working directory, and this caused
problems if tests were running in parallel with other build's tests.
This PR fixes those tests to all use `std.testing.tmpDir` to create unique
temporary names and directories.
Also clean the tests up to more consistently use `defer` to clean up, or
to just rely on tmpDir cleanup to remove individual files.
Working on these tests revealed a bunch of stale WASI code paths in
posix.zig, fixed by replacing stale `wast.AT.FDCWD` references with just
`AT.FDCWD`.
Fixes#14968.
* bcrypt: make silently_truncate_password a member of Params
This removes the need for having both `bcrypt()` and
`bcryptWithTruncation()` in the public API.
And whether truncation happens or not becomes even more explicit.
* Update crypto benchmark
