Unfortunately, this requires partially reverting
https://boringssl-review.googlesource.com/31324. This is a mess.
While clang proper includes a fuzzer driver, Chromium doesn't use it.
Chromium builds exclusively with fuzzer-no-link and links to its own
copy of the fuzzer runtime[1]. As of [2], Chromium's clang (which we use
on bots) no longer includes the driver, so we must mimic them.
However, Chromium's setup is somewhat questionable because
fuzzer-no-link pulls in libclang_rt.fuzzer_no_main which still includes
most of libclang_rt.fuzzer, just not the one main function[3]. It
appears Chromium is actually linking two copies of
libclang_rt.fuzzer_no_main. Hopefully this mostly works out as Chromium's
clang and libFuzzer should be relatively aligned, but it's not a good
assumption for our build, which can take other Clangs too.
Thus, if you pass -DFUZZ=1 as-is, we will assume you are using a
"normal" Clang with all its relevant runtimes intact. If, however, you
are using Chromium clang, you must drop the matching libFuzzer where the
bots expected it and build with -DLIBFUZZER_FROM_DEPS=1.
This involves no changes to the bots because we never actually unwound
all the LIBFUZZER_FROM_DEPS bits before.
[1] https://cs.chromium.org/chromium/src/testing/libfuzzer/BUILD.gn?rcl=d21c49585f262e851e2984f96f52905782706325&l=14
[2] c79bf2ea4c
[3] 8ebc3668b0/lib/fuzzer/CMakeLists.txt (L93-L107)8ebc3668b0/lib/fuzzer/FuzzerMain.cpp
Change-Id: I946b3c821c3d7e6def7e07f1381f58241611ba3d
Reviewed-on: https://boringssl-review.googlesource.com/c/34184
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
- In base.h, if BORINGSSL_PREFIX is defined, include
boringssl_prefix_symbols.h
- In all .S files, if BORINGSSL_PREFIX is defined, include
boringssl_prefix_symbols_asm.h
- In base.h, BSSL_NAMESPACE_BEGIN and BSSL_NAMESPACE_END are
defined with appropriate values depending on whether
BORINGSSL_PREFIX is defined; these macros are used in place
of 'namespace bssl {' and '}'
- Add util/make_prefix_headers.go, which takes a list of symbols
and auto-generates the header files mentioned above
- In CMakeLists.txt, if BORINGSSL_PREFIX and BORINGSSL_PREFIX_SYMBOLS
are defined, run util/make_prefix_headers.go to generate header
files
- In various CMakeLists.txt files, add "global_target" that all
targets depend on to give us a place to hook logic that must run
before all other targets (in particular, the header file generation
logic)
- Document this in BUILDING.md, including the fact that it is
the caller's responsibility to provide the symbol list and keep it
up to date
- Note that this scheme has not been tested on Windows, and likely
does not work on it; Windows support will need to be added in a
future commit
Change-Id: If66a7157f46b5b66230ef91e15826b910cf979a2
Reviewed-on: https://boringssl-review.googlesource.com/31364
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
I realized looking at the sigalgs parser that I messed up the
space-splitting logic slightly. If the CPU features are "foo bar baz",
it would not parse "baz". This doesn't particular matter (the last one
is "crc32"), but better to parse it correctly.
Fix this and add a unit test. While I'm here, may as well add a fuzzer
too.
Change-Id: Ifc1603b8f70d975f391d10e51ede95deec31a83d
Reviewed-on: https://boringssl-review.googlesource.com/31464
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
With Clang 6.0, libFuzzer is now included and there's a new
-fsanitize=fuzzer command to enable the needed compiler actions.
Change-Id: If8c0d649f494655c5bb1e55ebdbf39450940c75b
Reviewed-on: https://boringssl-review.googlesource.com/31324
Reviewed-by: David Benjamin <davidben@google.com>
Bug: 124
Change-Id: Iff02be9df2806572e6d3f860b448f598f85778c3
Reviewed-on: https://boringssl-review.googlesource.com/20107
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
There's not much point in enforcing this on these files, and clang
complains about LLVMFuzzerTestOneInput.
Change-Id: Ieae3287d7f7cd9736efd2b9fc11d0e6d89fcfa43
Reviewed-on: https://boringssl-review.googlesource.com/17806
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Change-Id: I69cbb0679e1dbb6292a8f4737851736e58c17508
Reviewed-on: https://boringssl-review.googlesource.com/12481
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This code has caused a long history of problems. This change rewrites it
completely with something that is, hopefully, much simplier and robust
and adds more testing.
Change-Id: Ibeef51f9386afd95d5b73316e451eb3a2d7ec4e0
Reviewed-on: https://boringssl-review.googlesource.com/8033
Reviewed-by: Adam Langley <agl@google.com>
We already had coverage for our new EVP_PKEY parsers, but it's good to have
some that cover them directly. The initial corpus was generated manually with
der-ascii and should cover most of the insanity around EC key serialization.
BUG=15
Change-Id: I7aaf56876680bfd5a89f5e365c5052eee03ba862
Reviewed-on: https://boringssl-review.googlesource.com/7728
Reviewed-by: Adam Langley <agl@google.com>
David Benjamin
Joshua Liebow-Feeser
Adam Langley
Steven Valdez
Robert Sloan
Adam Langley