search for: frandom

Yes, this is controlled by the -frandom-seed flag. Sadly, it is expected behavior. -Chris On Nov 12, 2010, at 7:10 AM, Sebastian Redl <sebastian.redl at getdesigned.at> wrote: > On 12.11.2010 15:26, Erik Cederstrand wrote: >> I have noticed that two consecutive builds of clang, clang++ and tblgen don't produce iden...

Oh, I should point out that using randomness is the unfortunate part, but you can get deterministic builds by passing -frandom-seed=0 to clang and/or gcc. -Chris On Nov 12, 2010, at 9:19 AM, Chris Lattner wrote: > Yes, this is controlled by the -frandom-seed flag. Sadly, it is expected behavior. > > -Chris > > On Nov 12, 2010, at 7:10 AM, Sebastian Redl <sebastian.redl at getdesigned.at> wrote:...

Den 12/11/2010 kl. 18.48 skrev Chris Lattner: > Oh, I should point out that using randomness is the unfortunate part, but you can get deterministic builds by passing -frandom-seed=0 to clang and/or gcc. I'll try that. I assume that the randomness has a purpose, so what are the negative implications of setting -frandom-seed=0? Will i still have a functioning compiler? :-) Thanks, Erik -------------- next part -------------- A non-text attachment was scrubbed... Nam...

> I'll try that. I assume that the randomness has a purpose, so what are the negative implications of setting -frandom-seed=0? Will i still have a functioning compiler? :-) The compiler being gcc? The manual says: The STRING should be different for every file you compile. > Thanks, > Erik Cheers, Rafael

I searched source code of LLVM/Clang 4.0.0 for 'random_seed' with grep. It seems the -frandom-seed option is not supported. The -rng-seed option appears to be defined in ./lib/Support/RandomNumberGenerator.cpp, which is source code for class RandomNumberGenerator. The constructor of class RandomNumberGenerator is private and is only called by Module::createRNG (defined in lib/IR/Module....

Hi, there, I am working on a project on software control flow checking, which instruments a program to check if the control flow at runtime matches the control flow graph computed at compile-time. My instrumentation process has to make use of control flow information, including as control flow graph and dominator/post-dominator trees, so it is better part of the compiler. On the other

...ic analyzer or any of the other protections offered by clang and llvm? It may suffice that there exists a niche which can't afford the performance penalty from asan or other things, but then we'll need to discuss what the performance impact is. 3. Reproducible builds are a must. GCC has a -frandom-seed=text flag and you should use that here too. Given the same random seed, the compiler shall produce the same output. Ultimately my concern here derives from the fact that I do use clang warnings today and I do use asan and ubsan today. If this ROP-protection were added, I don't immediately...

On 12.11.2010 15:26, Erik Cederstrand wrote: > I have noticed that two consecutive builds of clang, clang++ and tblgen don't produce identical binaries (as in md5 sums) on identical source code (I'm on FreeBSD). I ran strings(1) on the two clang binaries, and I get the following: > 251862c251862 > <

On Nov 12, 2010, at 7:10 AM, Sebastian Redl wrote: > On 12.11.2010 15:26, Erik Cederstrand wrote: >> I have noticed that two consecutive builds of clang, clang++ and tblgen don't produce identical binaries (as in md5 sums) on identical source code (I'm on FreeBSD). I ran strings(1) on the two clang binaries, and I get the following: >> 251862c251862 >> <

...configure llvm-gcc 2.6 with --target=mips or --target=mips-elf, I get: c++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -pedantic -Wno-long-long -Wno-variadic-macros -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -Wno-unused -DTARGET_NAME=\"mips-elf\" -frandom-seed=0 -I. -I. -I/home/foad/toolchain/llvm/llvm-gcc/gcc -I/home/foad/toolchain/llvm/llvm-gcc/gcc/. -I/home/foad/toolchain/llvm/llvm-gcc/gcc/../include -I/home/foad/toolchain/llvm/llvm-gcc/gcc/../libcpp/include -I/home/foad/toolchain/llvm/llvm-gcc/gcc/../libdecnumber -I../libdecnumber -I/home/foad/t...

Greetings LLVM Devs! I am a PhD student in the Secure Systems and Software Lab at UC Irvine. We have been working on adding randomness into code generation to create a diverse population of binaries. This diversity prevents code-reuse attacks such as return-oriented-programming (ROP) by denying the attacker information about the exact code layout. ROP has been used is several high-profile recent

Hello LLVM'ers I have noticed that two consecutive builds of clang, clang++ and tblgen don't produce identical binaries (as in md5 sums) on identical source code (I'm on FreeBSD). I ran strings(1) on the two clang binaries, and I get the following: 248400,248403c248400,248403 <

...hen we'll need to discuss what the performance impact is. Briefly looking at ASAN again, I saw a performance penalty of 2x mentioned. Diversity could act as both defense in depth, and as a lower-impact defense for performance critical code. > 3. Reproducible builds are a must. GCC has a -frandom-seed=text flag > and you should use that here too. Given the same random seed, the > compiler shall produce the same output. Completely agree, and that's exactly what we have done. > And one issue for us, the llvm developers. If we're going to accept > this feature, own it...

...very possible memory safety bug, either. I believe it's theoretically impossible for them to do so. Run-time protections are attractive because they can guarantee that some bad behavior does not happen in any execution of the program. > > 3. Reproducible builds are a must. GCC has a -frandom-seed=text flag > and you should use that here too. Given the same random seed, the > compiler shall produce the same output. > > Ultimately my concern here derives from the fact that I do use clang > warnings today and I do use asan and ubsan today. If this > ROP-protection we...

...g that I introduced/triggered >with the name changes. Yes I am now getting the following :- c++ -c -g -DIN_GCC -W -Wall -Wwrite-strings -pedantic -Wno-long-long -Wno-variad ic-macros -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -Wno-unused -DT ARGET_NAME=\"i686-pc-cygwin\" -frandom-seed=0 -I. -I. -I/home/ang/svn/llvm-gcc/g cc -I/home/ang/svn/llvm-gcc/gcc/. -I/home/ang/svn/llvm-gcc/gcc/../include -I/hom e/ang/svn/llvm-gcc/gcc/../libcpp/include -I/home/ang/svn/llvm-gcc/gcc/../libdec number -I../libdecnumber -I/home/ang/build/llvm/include -I/home/ang/svn/llvm/inc lude -DENABLE_L...

Hi Aaron, Which revision are you building? Assuming TOT, it's possible this is a bug that I introduced/triggered with the name changes. I know nothing of the status of cygwin however, can you confirm that this used to work? If you use r77097, does it work? - Daniel On Sun, Jul 26, 2009 at 4:23 AM, Aaron Gray<aaronngray.lists at googlemail.com> wrote: > I am getting an error

Hi Stephen, > Greetings LLVM Devs! > > I am a PhD student in the Secure Systems and Software Lab at UC > Irvine. We have been working on adding randomness into code generation > to create a diverse population of binaries. This diversity prevents > code-reuse attacks such as return-oriented-programming (ROP) by > denying the attacker information about the exact code layout.

...to randomize, etc? And if not *why can't we*? It's that last part which I think is hardest to answer, so I've decided I'll leave this to the security-trained folks -- if they think this is the right approach, they're probably right. 3. Reproducible builds are a must. GCC has a -frandom-seed=text flag and > you should use that here too. Given the same random seed, the compiler > shall produce the same output. > > Completely agree, and that's exactly what we have done. > > > And one issue for us, the llvm developers. If we're going to accept this >&...

I am getting an error building svn llvm-gcc on Cygwin :- /home/ang/build/llvm-gcc/./gcc/xgcc -B/home/ang/build/llvm-gcc/./gcc/ -B/usr/llv m-gcc/i686-pc-cygwin/bin/ -B/usr/llvm-gcc/i686-pc-cygwin/lib/ -isystem /usr/llvm -gcc/i686-pc-cygwin/include -isystem /usr/llvm-gcc/i686-pc-cygwin/sys-include - O2 -I/home/ang/svn/llvm-gcc/gcc/../winsup/w32api/include -O2 -g -O2 -DIN_GCC -W -Wall

Is anyone building dragon-egg on darwin? I am trying to build against the fink gcc45 package that I have prepared for darwin and a updated fink llvm 2.7 package that is built as... ../llvm-2.7/configure --prefix=/sw --prefix=/sw/lib/llvm --mandir=/sw/share/man --infodir=/sw/share/info --with-gmp=/sw --with-libiconv-prefix=/usr --with-system-zlib --with-as=/Developer/usr/bin/as