search for: canarying

Dear LLVMers, I am trying to measure the performance overhead (if any) of the canaries that clang inserts in the code. I would like to do this automatically, using the LLVM test infra-structure. However, I am not sure if that is possible. Could someone tell me which flags in the TEST.nightly.Makefile script, (or any other script) I must change to have this done? Usually I insert canaries with

I have a question about the performance of the implementation of the stack protector in LLVM. Consider the following C program: ===== void canary() { char buf[20]; buf[0]++; } int main() { int i; for (i = 0; i < 1000000000; ++i) canary(); return 0; } ===== This should definately run slower when stack protection is enabled, right? I have measured the runtime of

If you compile this with optimizations, then the 'canary()' function should be totally inlined into the 'main()' function. In that case, the cost of the stack protectors will be very small compared to the loop. -bw On Mar 9, 2012, at 2:52 AM, Job Noorman <jobnoorman at gmail.com> wrote: > I have a question about the performance of the implementation of the stack >

Hi all, I want to implement the Xor random canary, so I have to get the return address in the prologue and epilogue of the function. In the prologue of the function, before I insert into the canary on the stack, I can get the return address by: ConstantInt* ci = llvm::ConstantInt::get(Type::getInt32Ty(RI->getContext()), 0); Value* Args1[] = {ci}; CallInst* callInst =

I''m trying to figure out how I can pin the CPU affinity for individual domU''s in their configuration file. I allocated 3 CPUs to a particular domU, and the CPU affinity is floating between those three. I want to pin them to specific cores in the config file. I can do it on bootup by doing vcpu-pin on the command-line, but I want this to be set int he config file itself. Right

Hi all, I am master student in Edinburgh, UK. I am doing my MSc project with LLVM compiler and I have to modify LLVM to implement the StackGuard with a XOR random Canary. However, I am not familiar with LLVM. My problem is that I want to XOR the random canary word with the return address which are both 32 bits. I found a method called SimplifyXorInst(Value *, Value *, const TargetData

John Criswell wrote: > If you're interested in SAFECode, the first step is to get SAFECode > working with a newer version of LLVM. A Master's student did some > work on this last summer with LLVM 3.7 but didn't finish. It would > now need to be updated to LLVM 3.8 (though I suppose a completed LLVM > 3.7 port would be fine with me). > > After that, there are

People, Anybody knows what mean this message in my CLI: [Apr 1 16:58:34] WARNING[3845]: asterisk.c:3050 canary_thread: The canary is no more. He has ceased to be! He's expired and gone to meet his maker! He's a stiff! Bereft of life, he rests in peace. His metabolic processes are now history! He's off the twig! He's kicked the bucket. He's shuffled off his mortal

All, I just noticed this in my logs, and am rather lost as to what module it pertains to. I would assume pseudo-realtime priority for the process, but I am looking for a little confirmation from the group: [Apr 28 12:28:36] WARNING[20773] asterisk.c: The canary is no more. He has ceased to be! He's expired and gone to meet his maker! He's a stiff! Bereft of life, he rests in

On Thu, Jun 30, 2016 at 8:29 AM, Martin J. O'Riordan via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I am trying to implement stack probes for our SHAVE target, and I see that > the compiler injects references to ‘__stack_chk_guard’ and > ‘__stack_chk_fail’. The code that gets generated is horribly wrong, but in > order to understand how to fix it I was wondering if

I am trying to implement stack probes for our SHAVE target, and I see that the compiler injects references to '__stack_chk_guard' and '__stack_chk_fail'. The code that gets generated is horribly wrong, but in order to understand how to fix it I was wondering if there is a clear statement of how the mechanism is supposed to work? The variable '__stack_chk_guard' appears

On 7/26/11 5:37 PM, Xueying ZHANG wrote: > Hi John, > > Thanks for your reply! I'm CC'ing this to the list in case anyone knows why you're seeing this behavior. > > Now, I know the different between llvm.returnaddress(0) and > llvm.returnaddress(1). I modify the StackPortector.cpp and I just want > to get value of the return address stored on the stack. >

I'm using bleeding-edge R-devel, so maybe my build is weird. Can anyone else reproduce this? View() seems to crash on just about anything. View(1:3) *** stack smashing detected ***: terminated Aborted (core dumped) If I debug(View) I get to the last line of code with nothing obviously looking pathological: Browse[1]> debug: invisible(.External2(C_dataviewer, x, title))

On Tuesday 10 March 2009 21:47:59 someguy wrote: > From a cursory glance, it looks like something is messing with the > stack canarys. Probably a stack buffer overflow. In case it is relevant, HLVM uses libsigsegv to detect stack overflows and that stack handler is initialized in my JITted code which LLVM's runFunction should be calling. Could libsigsegv be conflicing with the stack

Hi all, How to XOR the return address on the stack with a canary word both are 32 bits? Is there a method to implement it? Thank you. Ying -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

Dear Duncan, thank you very much. I have been able to use it now, via the following command line: clang -emit-llvm -c -fstack-protector canary.c -o canary.bc llc -print-before=stack-protector -print-after=stack-protector -o canary.s < canary.bc Thank you again, Izabela Maffra. On 26 January 2013 15:55, <llvmdev-request at cs.uiuc.edu> wrote: > Send LLVMdev mailing

On Mar 10, 2009, at 3:07 PM, Jon Harrop wrote: > On Tuesday 10 March 2009 21:47:59 someguy wrote: >> From a cursory glance, it looks like something is messing with the >> stack canarys. Probably a stack buffer overflow. > > In case it is relevant, HLVM uses libsigsegv to detect stack > overflows and > that stack handler is initialized in my JITted code which

Hi all, I am master student in Edinburgh, UK. I am doing my MSc project with LLVM compiler and I have to modify LLVM to implement the StackGuard with a XOR random Canary. However, I am not familiar with LLVM. My problem is that I want to XOR the random canary word with the return address which are both 32 bits. I found a method called SimplifyXorInst(Value *, Value *, const TargetData

Hello > In the prologue of the function, before I insert into the canary on > the stack, I can get the return address by: Note that there is no epilogue and prologue at IR level :) > But it does not work this time. I cannot get the return address. > What is problem? How can I get the return address? Thank you! What is the problem? It seems you're getting the return address via

From: Joerg Roedel <jroedel at suse.de> Make sure segments are properly set up before setting up an IDT and doing anything that might cause a #VC exception. This is later needed for early exception handling. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/kernel/head_64.S | 52 +++++++++++++++++++-------------------- 1 file changed, 26 insertions(+), 26 deletions(-)