[cfe-users] Stack buffer overflow protection
I'm porting software to Apple's Clang 7.0, as released in Xcode 7.0. I'm not clear how that version number relates to the Clang 3.x version numbers. I'm interested in turning on checking for stack buffer overflows. There's the GCC option -fstack-protector, and then there's the SafeStack sanitizer, http://clang.llvm.org/docs/SafeStack.html. However, that doesn't support linking DSOs, and that's actually vital for my purposes: the product I'm working on is mathematical modelling libraries, delivered as DSOs. So I think -fstack-protector is what I need to use, but I can't find any Clang documentation about it. Any suggestions? thanks, -- John Dallman - Siemens Industry Software Limited is a limited company registered in England and Wales. Registered number: 3476850. Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD. ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Stack buffer overflow protection
> I'm porting software to Apple's Clang 7.0, as released in Xcode 7.0. I'm not > clear how that > version number relates to the Clang 3.x version numbers. clang -v reveals that Apple LLVM 7.0.0 is based on LLVM 3.7.0svn. > So I think -fstack-protector is what I need to use, but I can't find any > Clang documentation about it. Any suggestions? Experimenting with clang -v and the various -stack-protector options reveals that Clang as far back LLVM3.1 has used -fstack-protector by default, and has -fstack-protector-all. Clang from LLVM 3.7 implements -fstack-protector-strong, which seems like the sensible thing to try as an upgrade from the basic -fstack-protector. -- John Dallman - Siemens Industry Software Limited is a limited company registered in England and Wales. Registered number: 3476850. Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD. ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] Clang equivalent to -fsignalling-nans?
I'm using a new version of Clang from Apple, targeting macOS 10.12, which comes from an Xcode that is still in beta. I'm compiling C code, rather than C++. I'm hitting problems with the compiler assuming that floating-point divides won't trap, and executing them speculatively, in advance of the conditions that prevent the traps going off. Previous versions of Clang didn't do this, but it's causing me difficulties, because the product I work on is tested with Overflow, Invalid and Divide-by-zero traps enabled: this makes it much easier to find problems than by tracing back through lots of NaNs. I can't find anything that seems relevant in the Clang user's manual at http://clang.llvm.org/docs/UsersManual.html. The GCC 4.2 documentation has three options that look possibly relevant. -ftrapping-math and -fnon-call-exceptions are accepted by Clang, but don't seem to make any difference to the problematic source; -fsignaling-nans is not supported by Clang, and the message is quite clear about that. Turning optimisation right off with -O0 suppresses the problem, but is really bad for performance: we've been able to build and work effectively at -O2 for several years with Apple's Clang releases. Am I missing an option somewhere, or does this look like a bug that I need to report? thanks, -- John Dallman - Siemens Industry Software Limited is a limited company registered in England and Wales. Registered number: 3476850. Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD. ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] Prospects of Clang acquiring an equivalent of MSVC's /QSpectre?
As far as I've been able to learn, the only way to avoid security vulnerabilities due to Spectre variant 1 (CVE-2017-5753, "bounds check bypass") is to insert fences to control the relevant speculative reads. I'm interested in doing this because I work on a numerical modelling library that is used in many applications, which are used to handle valuable information. There's been at least one piece of malware that specifically targeted one of those applications, so I work at a moderate level of paranoia. I've found information about __builtin_load_no_speculate, but inserting those by hand into ten million lines of branchy C code that's under active development is not an attractive prospect. MSVC has recently gained a /QSpectre option that tries to do this for you (https://blogs.msdn.microsoft.com/vcblog/2018/01/15/spectre-mitigations-in-msvc/). While this can't be completely fool-proof, I can well believe that it will do as good a job as bored humans, and is much cheaper. Are there any plans to add something equivalent to Clang? -- John Dallman - Siemens Industry Software Limited is a limited company registered in England and Wales. Registered number: 3476850. Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD. ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Prospects of Clang acquiring an equivalent of MSVC's /QSpectre?
> MSVC has recently gained a /QSpectre option that tries to do this for you > (https://blogs.msdn.microsoft.com/vcblog/2018/01/15/spectre-mitigations-in-msvc/). > While this can't be completely fool-proof, I can well believe that it will do > as good a job as bored humans, and is much cheaper. I was a bit optimistic there: currently it is very limited. https://www.paulkocher.com/doc/MicrosoftCompilerSpectreMitigation.html has details. Nonetheless, automated tools are going to be essential to fix this problem. -- John Dallman - Siemens Industry Software Limited is a limited company registered in England and Wales. Registered number: 3476850. Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD. ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] Floating-point traps on x86-64
I produce a mathematical modelling library on several platforms, including iOS, macOS and Android, all of which use Clang. Where the hardware can generate floating-point traps, I prefer to run testing with traps for Invalid Operation, Divide-by-Zero and Overflow turned on, since that finds me problem sites more quickly than working backwards from "this test case failed." However, I had a problem with Apple Clang 8.x, which I believe was LLVM 3.9, targeting x86-64, in that the optimiser was assuming that floating-point traps were turned off. This was shown, for example, by the way it hoisted floating-point divides above tests of the divisor that were meant to safeguard the divides. After a long support case with Apple, they gave me some Clang command-line options for LLVM that suppressed the problem: -mllvm -speculate-one-expensive-inst=false -mllvm -bonus-inst-threshold=0 I appreciate that this costs some performance, and I can accept that. These options worked fine for Apple Clang 9.x, whose various versions seem to have been based on LLVM 4.x and 5.x. Now I've come to Apple Clang 10.0, which seems to be based on LLVM 6.0.1, and I have lots of floating-point traps again in optimised x86-64 code. It seems possible that I need some further LLVM options: does this seem plausible? I'm not familiar with the LLVM codebase, and while I can find the source files that list the options I can use with -mllvm, I'd be guessing at which options are worth trying. Can anyone make suggestions? Thanks very much, -- John Dallman - Siemens Industry Software Limited is a limited company registered in England and Wales. Registered number: 3476850. Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD. ___ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Building with Clang (on Windows) - but for Linux
> BTW - I often see Clang described as "llvm" or "cfe" and I've often wondered > what they stand for ?? LLVM is "Low Level Virtual Machine". That name is a bit confusing, because this isn't the kind of "Virtual Machine" you get from VMWare or the like, but a way of representing programs for a non-existent, hence "virtual," computer architecture. It was created for use in compilers: you have a front-end that translates programming languages into the LLVM representation, and a back-end that generates object files for a specific processor and operating system. That means that to create compilers for X different languages to run on Y different platforms, you only need to write X front-ends and Y backends, rather than X*Y separate compilers. "cfe" is the "C front-end" which also handles C++ and the "Objective" variants of C and C++. https://en.wikipedia.org/wiki/LLVM The idea of having a well-defined intermediate representation for compilers and related tools has been around for nearly sixty years (https://en.wikipedia.org/wiki/CPL_(programming_language)) but LLVM seems to be the most successful implementation to date. -- John Dallman - Siemens Industry Software Limited is a limited company registered in England and Wales. Registered number: 3476850. Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD. ___ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
