similar to: [LLVMdev] SafeStack pass and TLS support

Hi Tim, Thanks for the thorough explanation. It makes perfect sense. I was not aware fast-math is supposed to prevent more precision being used than what is in the standard. I came across this issue while looking into the output or different compilers. XL and Microsoft compiler seem to have that turned on by default. But I assume that clang follows what gcc does, and have that turned off.

On 2/7/2017 20:02, Kostya Serebryany wrote: > ... > > My understanding is that BNDCU is the cheapest possible instruction, > just like XOR or ADD, > so the overhead should be relatively small. > Still my guesstimate would be >= 5% since stores are very numerous. > And such overhead will be on top of whatever overhead SafeStack has. > Do you have any measurements to

It seems the crash of llvm/clang build on aarch64 Debian has been fixed by r220941. Thanks, -Jiangning 2014-11-05 8:45 GMT+08:00 Jiangning Liu <liujiangning1 at gmail.com>: > The versions I'm using right now are > > * gcc: (Debian/Linaro 4.9.1-14) 4.9.1 > * libstdc++: libstdc++.so.6.0.20 > > Thanks, > -Jiangning > > 2014-11-05 4:46 GMT+08:00 Chris Bieneman

Hi Kostya, >On Wed, Nov 12, 2014 at 2:50 AM, Volodymyr Kuznetsov <vova.kuznetsov at epfl.ch >> wrote: > >> Dear LLVM developers, >> >> We've applied the feedback we received on Phabricator on the SafeStack >> patches, >> > >Did you investigate the possibility of moving the transformation from >codegen to the LLVM level, i.e. the same level

Hi, I would like to use SafeStack sanitize option on ARM platform. Since Linux libc does not implement such functionality (in opposite to FreeBSD or Android), I need to use SafeStack compiler RT library. Unfortunately I've noticed that libclang_rt.safestack is not compiled/built for ARM platform. Looking into cmake file: "set(ALL_SAFESTACK_SUPPORTED_ARCH ${X86} ${X86_64} ${ARM64}

+nlewycky On Mon, Nov 17, 2014 at 9:36 AM, Volodymyr Kuznetsov <vova.kuznetsov at epfl.ch > wrote: > Hi Kostya, > > On Sat, Nov 15, 2014 at 1:53 PM, Volodymyr Kuznetsov < > vova.kuznetsov at epfl.ch> wrote: > > Do you think moving the pass to lib/Transform/Instrumentation but > > scheduling it during code generation would make sense ? If so, we'll >

On Mon, 2014-09-08 at 22:00 -0400, Samuel F Antao wrote: > Alexey, Alexander, > > Thanks for the suggestions. I tried removing the flag SA_NODEFER but > it didn't do any good... I have been digging into the problem with the > null_deref test today but I was unable to clearly identify the > problem. I suspect that it was either a bug with the calling > convention/unwinding

Hi all, The AllowFPOpFusion option passed to a target can currently take 3 different values, Fast, Standard or Strict (TargetOptions.h), being Standard the default. In the DAGCombiner, during the combination of mul and add/subtract into multiply-and-add/subtract, this option is expected to be Fast in order to enable the combine. This means, that by default no multiply-and-add opcodes are going

Note that I've set the SA_NODEFER flag for the SEGV handler in the ASan runtime only a couple of days ago. Not sure that could've affected this test though; without that flag the second SEGV would've simply crashed the program. But you can try removing the flag from compiler-rt/trunk/lib/sanitizer_common/sanitizer_posix_libcdep.cc and see if that makes any difference. HTH, Alex On

On Mon, Sep 8, 2014 at 7:00 PM, Samuel F Antao <sfantao at us.ibm.com> wrote: > Alexey, Alexander, > > Thanks for the suggestions. I tried removing the flag SA_NODEFER but it > didn't do any good... I have been digging into the problem with the > null_deref test today but I was unable to clearly identify the problem. I > suspect that it was either a bug with the

Ok, I'll put a patch together to fix this later today. I'll probably do what Reid was suggesting and use what is already in there for Windows. Thanks, Samuel Bill Schmidt <wschmidt at linux.vnet.ibm.com> wrote on 11/04/2014 12:11:08 PM: > From: Bill Schmidt <wschmidt at linux.vnet.ibm.com> > To: Samuel F Antao/Watson/IBM at IBMUS > Cc: azanella at

Hi all, I observe that r220932 (Removing the static initializer in ManagedStatic.cpp by using llvm_call_once to initialize the ManagedStatic mutex.) is causing tablegen to segfault in PPC platforms during static initialization. The crash happens while calling std::call_once introduced by this patch in the wrapper used in getManagedStaticMutex. I understand this call is buggy for some platforms

Hal, Johannes, Thanks for the feedback. I have been digging into this a little bit more and was able to have some of this metadata being generated. Nevertheless, I am confused about the semantics of this metadata. Let me explain: I was expecting the alias metadata to complement the information that alias analysis passes compute. However, it seems that the alias information of the pointers used

Adding Jiangning Liu to the thread. Jiangning reported a similar issue on the llvm-commits list on Debian aarch64. In general it sounds like std::call_once may not really be bug free. Jiangning, can you please provide your gcc/libstdc++ version? Thanks, -Chris > On Nov 4, 2014, at 9:38 AM, Bill Schmidt <wschmidt at linux.vnet.ibm.com> wrote: > > On Tue, 2014-11-04 at 12:17

Hi Bill, You can find the same issue in the buildbot: http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2/builds/16444/steps/compile.llvm.stage2/logs/stdio It is failing for me both in BE (gcc 4.8.2) and LE(4.9.1). I am compiling with clang 3.5, but those are the gcc toolchains I am using. What do you think is the best way to fix this? Thanks! Samuel Bill Schmidt <wschmidt at

Hi, I previously posted about using 32-bit X86 segmentation to harden SafeStack: http://lists.llvm.org/pipermail/llvm-dev/2016-May/100346.html That involves lowering the limits of the DS and ES segments that are used for ordinary data accesses while leaving the limit for SS, the stack segment, set to its maximum value. The safe stacks were clustered above the limits of DS and ES. Thus, by

Dear LLVM developers, Our team has developed an LLVM-based protection mechanism that (i) prevents control-flow hijack attacks enabled by memory corruption errors and (ii) has very low performance overhead. We would like to contribute the implementation to LLVM. We presented this work at the OSDI 2014 conference, at several software companies, and several US universities. We received positive

Hello, I'm in the process of creating a pass for the new PM for SafeStack which is only available as a part of the legacy PM. The only thing bugging me is in regards to the TargetPassConfig analysis. Whereas most other passes/analyses I have seen separate the logic between the actual pass and anything it does to the IRUnits it runs over are in 2 separate classes, TargetPassConfig has them

Hi, SafeStack currently relies on address randomization to protect the safe stack. If the location of a safe stack is somehow revealed and a corrupted pointer references it, then a safe stack can be corrupted. The creators of SafeStack envisioned the possibility of using X86 segmentation to further harden SafeStack against such corruption (see the comment near the top of

On 4 Nov 2014, at 00:36, Kostya Serebryany <kcc at google.com> wrote: > You at least increase the memory footprint by doubling the stack sizes. Not quite. The space overhead is constant for each stack frame - you just need to keep track of the top of two stacks, rather than one. The important overhead is that you reduce locality of reference. You will need a minimum of two cache