LLVM trace-pc mode build failed using Clang 10.0.0-svn371489 #30

hongxuchen · 2019-09-11T15:17:07Z

I was trying AFL-2.54b with the LLVM trace_pc_guard feature, however it failed to build with LLVM 10.0.0-svn371489 (of course, I commented out -sanitizer-coverage-block-threshold=0 related lines in afl-clang-fast.c).

The error message is like:

So it turns out that the execution traces are unexpectedly the same when the inputs are 0 and 1, which can be confirmed by observing the following results:

I got LLVM/Clang from https://apt.llvm.org (Ubuntu 18.04.2 LTS).

I also tried building AFL-2.54b with LLVM-4.0, where there are no issues for builds, and the trace_pc_mode seems working on projects such as exiv2.

Meanwhile, I tried AFLplusplus with the same LLVM/Clang build tools (v10.0), it builds and tests without errors, despite that compared to AFL-2.54b I can see no big changes for the trace_pc_guard feature.

The text was updated successfully, but these errors were encountered:

jonathanmetzman · 2019-09-11T15:47:27Z

Hmmm....I just successfully ran AFL_USE_TRACE_PC=1 make clean all with an LLVM/clang from trunk (00c1ee48e4cf2a6ce67dc96342b1b07625d0a7b4) (with and without -sanitizer-coverage-block-threshold=0 commented out).

I'm not sure what to make of the fact that it works fine for AFLplusplus either.

jonathanmetzman · 2019-09-11T15:58:35Z

I was also unable to reproduce this problem using clang version 10.0.0-svn371576-1~exp1+0~20190911001019.2477~1.gbp13c8b7 (trunk) on ubuntu 16.04.6 that I installed from https://apt.llvm.org.

Are you sure the details of your local setup are correct? Maybe this particular version of clang is broken and if you try again it will work.

jonathanmetzman · 2019-09-11T15:59:48Z

of course, I commented out -sanitizer-coverage-block-threshold=0 related lines in afl-clang-fast.c

Could you explain why you do this btw? When use trace-pc-guard we don't use afl-clang-fast and we don't use this flag, so if there is a reason not to do it, I'd be happy to get rid of it from afl-clang-fast in general.

vanhauser-thc · 2019-09-12T08:10:57Z

I can explain why this happens, as we had/have the same issue, and it has nothing to do the the pcguard feature.

Starting with llvm 9 the optimizer is very strong and so what happens because all that is different in the program output of 0 and 1 is the printf parameter, that is all that is changed via an index pointer, hence the exact basic blocks are visited for both inputs.

so what we did (or hexcoder who found that issue and fixed it), is that we use 0 (or 1) as the first test input, and " < /dev/null" as the second, as this triggers a different code path.

hongxuchen · 2019-09-12T08:31:31Z

On Wed, Sep 11, 2019 at 11:59 PM jonathanmetzman ***@***.***> wrote: of course, I commented out -sanitizer-coverage-block-threshold=0 related lines in afl-clang-fast.c Could you explain why you do this btw? When use trace-pc-guard we don't use afl-clang-fast and we don't use this flag, so if there is a reason not to do it, I'd be happy to get rid of it from afl-clang-fast in general.

LLVM replaced "-sanitizer-coverage-block-threshold" with "--sanitizer-coverage-level" in certain commit (probably in LLVM 5.0) and make it default to 0. Without commenting out the related lines in afl-clang-fast.c, my builds of AFL reports something like "Unknown command line argument '-sanitizer-coverage-block-threshold=0'. Try: 'clang (LLVM option parsing) --help'". I think afl-clang-fast needs that option when LLVM sanitizer trace pc guard mode is used, in which scenario afl-llvm-rt.o.c implements the callbacks __sanitizer_cov_trace_pc_guard_init and __sanitizer_cov_trace_pc_guard, rather than relies on afl-llvm-pass.so.

…

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#30?email_source=notifications&email_token=AAGN4A6SHIKS7HLTW7BE33TQJEIXPA5CNFSM4IVVMHI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6O7YGI#issuecomment-530447385>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGN4AYAJXUPMYE26SKYB2TQJEIXPANCNFSM4IVVMHIQ> .

hongxuchen · 2019-09-12T08:51:45Z

On Thu, Sep 12, 2019 at 4:11 PM van Hauser ***@***.***> wrote: I can explain why this happens, as we had/have the same issue, and it has nothing to do the the pcguard feature. Starting with llvm 9 the optimizer is very strong and so what happens because all that is different in the program output of 0 and 1 is the printf parameter, that is all that is changed via an index pointer, hence the exact basic blocks are visited for both inputs.

Yes! Confirmed with the generated "test-instr" on my machine.

so what we did (or hexcoder who found that issue and fixed it), is that we use 0 (or 1) as the first test input, and " < /dev/null" as the second, as this triggers a different code path.

Nice trick! Perhaps a more complicated test program that dumbs the optimizer is better:)

…

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#30?email_source=notifications&email_token=AAGN4A5Q47ZOVTMRKUOD32TQJH2RJA5CNFSM4IVVMHI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6RBOHQ#issuecomment-530716446>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGN4A5ROGLLIFKHIUX6SE3QJH2RJANCNFSM4IVVMHIQ> .

jonathanmetzman · 2019-09-12T18:17:39Z

I can explain why this happens, as we had/have the same issue, and it has nothing to do the the pcguard feature.

Starting with llvm 9 the optimizer is very strong and so what happens because all that is different in the program output of 0 and 1 is the printf parameter, that is all that is changed via an index pointer, hence the exact basic blocks are visited for both inputs.

so what we did (or hexcoder who found that issue and fixed it), is that we use 0 (or 1) as the first test input, and " < /dev/null" as the second, as this triggers a different code path.

Thanks @vanhauser-thc I'll change the test when I get a chance (probably tomorrow).

RootUp · 2019-09-17T20:34:34Z

Just to add, I encountered the similar issue.

$ AFL_USE_TRACE_PC=1 make clean all
rm -f *.o *.so *~ a.out core core.[1-9][0-9]* test-instr .test-instr0 .test-instr1 
rm -f ../afl-clang-fast ../afl-llvm-pass.so ../afl-llvm-rt.o ../afl-llvm-rt-32.o ../afl-llvm-rt-64.o ../afl-clang-fast++
[*] Checking for working 'llvm-config'...
[*] Checking for working 'clang'...
[*] Checking for '../afl-showmap'...
[+] All set and ready to build.
clang -O3 -funroll-loops -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign -DAFL_PATH=\"/usr/local/lib/afl\" -DBIN_PATH=\"/usr/local/bin\" -DVERSION=\"2.52b\"  afl-clang-fast.c -o ../afl-clang-fast 
ln -sf afl-clang-fast ../afl-clang-fast++
clang++ `llvm-config --cxxflags` -fno-rtti -fpic -O3 -funroll-loops -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign -DVERSION=\"2.52b\" -Wno-variadic-macros -shared afl-llvm-pass.so.cc -o ../afl-llvm-pass.so `llvm-config --ldflags` 
warning: unknown warning option '-Wno-maybe-uninitialized'; did you mean '-Wno-uninitialized'? [-Wunknown-warning-option]
1 warning generated.
clang -O3 -funroll-loops -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign -DAFL_PATH=\"/usr/local/lib/afl\" -DBIN_PATH=\"/usr/local/bin\" -DVERSION=\"2.52b\"  -fPIC -c afl-llvm-rt.o.c -o ../afl-llvm-rt.o
[*] Building 32-bit variant of the runtime (-m32)... failed (that's fine)
[*] Building 64-bit variant of the runtime (-m64)... success!
[*] Testing the CC wrapper and instrumentation output...
unset AFL_USE_ASAN AFL_USE_MSAN AFL_INST_RATIO; AFL_QUIET=1 AFL_PATH=. AFL_CC=clang ../afl-clang-fast -O3 -funroll-loops -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign -DAFL_PATH=\"/usr/local/lib/afl\" -DBIN_PATH=\"/usr/local/bin\" -DVERSION=\"2.52b\"  ../test-instr.c -o test-instr 
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script.
clang: error: unable to execute command: Segmentation fault
clang: note: diagnostic msg: Error generating preprocessed source(s).
Makefile:97: recipe for target 'test_build' failed
make: *** [test_build] Error 254

jonathanmetzman · 2019-09-17T22:29:20Z

Thanks for the report. I've put up #33 to fix this.

Make tests using ./test-instr use paths that are less likely to be optimized out.

jonathanmetzman mentioned this issue Sep 11, 2019

Figure out what do with lcamtuf's email address #32

Open

jonathanmetzman mentioned this issue Sep 17, 2019

Make Makefile tests handle optimization more gracefully. #33

Merged

jonathanmetzman closed this as completed in #33 Sep 17, 2019

jonathanmetzman added a commit that referenced this issue Sep 17, 2019

Make Makefile tests handle optimization more gracefully. (#33) (#30)

1f414d5

Make tests using ./test-instr use paths that are less likely to be optimized out.

lromerio mentioned this issue May 7, 2020

Compilation fails when using LLVM 9 puppet-meteor/MOpt-AFL#3

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

LLVM trace-pc mode build failed using Clang 10.0.0-svn371489 #30

LLVM trace-pc mode build failed using Clang 10.0.0-svn371489 #30

hongxuchen commented Sep 11, 2019 •

edited

Loading

jonathanmetzman commented Sep 11, 2019 •

edited

Loading

jonathanmetzman commented Sep 11, 2019

jonathanmetzman commented Sep 11, 2019

vanhauser-thc commented Sep 12, 2019

hongxuchen commented Sep 12, 2019 via email •

edited

Loading

hongxuchen commented Sep 12, 2019 via email

jonathanmetzman commented Sep 12, 2019

RootUp commented Sep 17, 2019

jonathanmetzman commented Sep 17, 2019

LLVM trace-pc mode build failed using Clang 10.0.0-svn371489 #30

LLVM trace-pc mode build failed using Clang 10.0.0-svn371489 #30

Comments

hongxuchen commented Sep 11, 2019 • edited Loading

jonathanmetzman commented Sep 11, 2019 • edited Loading

jonathanmetzman commented Sep 11, 2019

jonathanmetzman commented Sep 11, 2019

vanhauser-thc commented Sep 12, 2019

hongxuchen commented Sep 12, 2019 via email • edited Loading

hongxuchen commented Sep 12, 2019 via email

jonathanmetzman commented Sep 12, 2019

RootUp commented Sep 17, 2019

jonathanmetzman commented Sep 17, 2019

hongxuchen commented Sep 11, 2019 •

edited

Loading

jonathanmetzman commented Sep 11, 2019 •

edited

Loading

hongxuchen commented Sep 12, 2019 via email •

edited

Loading