* [ghostscript] Replace deprecated flag by current flag.
In old versions of Ghostscript the flag -dPARANOIDSAFER did
more checks than -dSAFER did. In modern versions the two flags
are identical. Moreover the flag -dPARANOIDSAFER has been
deprecated for a long time, and may be removed in the future.
In Ghostscript 9.50 and later -dSAFER is the default, and does
not have to be specified. To be able to test older yet still
modern Ghostscript versions without problems -dSAFER is used.
* [ghostscript] Force enable banding while rendering.
Ghostscript uses the set resolution to determine if banding should be
enabled during rendering, or not. Under normal circumstances documents
are rendered at maybe 600 DPI, but to conserve memory while running in
OSS-fuzz 200 DPI is used (-r200x200). To still test the banding code
used under normal circumstances banding is force enabled.
Moreover BufferSpace is used to determine the band height and thus the
number of bands. At 600 DPI this is normally 4Mbyte, so a reasonable
approximate at 200 DPI is 450k. Thus BufferSpace is also set.
* [ghostscript] Enable another sanitizer to see more issues.
Apparently the maximum memory usage is 2.5Gbyte so a limit of 3Gbyte
is to liberal. Set limit to 1Gbyte to make sure that any extra memory
used by the fuzzer is allowed. 1Gbyte ought to be enough for most real
world images decoded by jbig2dec.
* grok: add dataflow support
* clean up in Dockerfile
* remove dataflow
Co-authored-by: Max Moroz <balalaikacr3w@gmail.com>
Co-authored-by: Max Moroz <mmoroz@chromium.org>
After many days banging my head on FFI issues in rust,
I hereby present a fix to the issue.
Note that I've got some help, and I'm not sure I understand everything here.
But this is my understanding of what was not working, and how we fixed it.
The **problem** is that on Ubuntu 16 with llvm/clang 10,
we were **statically linking libc++** in [rocksdb][1]:
```rust
let stdlib = if tool.is_like_gnu() {
"libstdc++.a"
} else if tool.is_like_clang() {
"libc++.a"
} else {
// Don't link to c++ statically on windows.
return;
};
// ...
// remove lib prefix and .a postfix.
println!(
"cargo:rustc-link-lib=static={}",
&stdlib[3..stdlib.len() - 2]
);
```
This means that during building, when we reach building of rocksdb,
we import a number of symbols from libc++ (like [__muloti4][2])
that end up in the associated `.rlib` (rust obj file).
These symbols interestingly do not exist in libstdc++ which is used by gcc.
This is important because on linux (unlike mac), the rust toolchain is compiled with gcc.
So these intrinsics are not present in the linux rust toolchain,
and have been redeclared in the [compiler-builtins][3] crate.
So here is the problem:
* rust toolchain's defines these intrinsics functions
* libc++ defines these intrinsics functions
And the recipe for disaster:
* libc++ is statically linked in rocksdb, which means all the symbols are imported
* symbols in rocksdb's produced `.rlib` are colliding with the symbols from the rust toolchain `.rlib`
To fix this. Maybe we could have compiled the stuff with libstdc++?
But instead we:
1. removed the static linking
2. we linked libc++ at the very last moment via:
```rust
RUSTFLAGS="-C link-arg=-L/usr/local/lib -C link-arg=-lc++"
```
At final linking time, the linker sees that the intrinsics are already defined in one of the `.rlib`
(produced by compiler-builtins) and so does not import these functions from libc++.
Actually, at this point it only statically link the functions that need to be linked.
It seems to work.
[1]: c79d2c2ac6/librocksdb_sys/build.rs (L115)
[2]: https://github.com/llvm-mirror/libcxx/blob/master/src/filesystem/int128_builtins.cpp
[3]: e578d47247/src/int/mul.rs (L107)
* Added xpdf project.
* Tried linking with cxx.
* Since the executables build are not needed for the fuzzer build to succeed we can ignore the case where some test-apps are not build on the oss-fuzz platform.
* Ignore errors that dont impact the fuzzers.
* Updated the project file with language field.
[bignum-fuzzer] Mbed TLS no longer has an mbed-crypto submodule
Mbed TLS has gone back to being self-contained, without a separate
submodule for the cryptography part of the library. Revert the
bignum-fuzzer build scripts accordingly.
This reverts commit 54733ddc84.
Previously raster output data was printed on stdout. While this
is similar to how Ghostscript is run by CUPS's gstoraster filter it
unnecessarily prolongs execution time for many files.
Changing the output file still means that CUPS will be sent the
rasterized page and will be asked to convert it to a PWG raster which
it then dutifully writes to /dev/null. Thus no major difference is
expected in what code is executed in Ghostscript (or CUPS).
When run locally on a testcase found among the problematic files here:
gs://ghostscript-corpus.clusterfuzz-external.appspot.com/libFuzzer/
fuzzer target reported a timeout after 120 seconds before this commit.
After this commit the fuzzer target succeeded after about 3 seconds.
We need to disable all supported tctis for fuzzing.
This includes recently added swtpm.
Also switch the option from --enable-<module>=no
to preferred --disable-<module>
Signed-off-by: Tadeusz Struk <tstruk@gmail.com>
* Adds project quickjs
* Activate ubsan for quickjs
* Loop for fuzz targets
* Revert "Activate ubsan for quickjs"
This reverts commit 55678410ad.
* Language for quickjs
* Updated with improvements so we (0) build the /bintuls applications (1) targets for readelf (with sample ELF file) and cxxfilt and (3) added my email to the project yaml.
Fixed travis.
Removed whitespace and fixed commit email for google cla
Fixed travis.
Removed whitespace and fixed commit email for google cla
* Added Dovecot project.
* Updated the build script to reflect updates in Dovecot where we have integrated the build process into the actual project.
* Fixup emails.
* Updated build with new branch.
* Updated to new build options.
* Fix travis.
Sebastian Rasmussen