similar to: Fatpointer Pass already existing?

Hi John, On 25 May 2016 at 16:11, John Criswell <jtcriswel at gmail.com> wrote: > Dear Pierre, > > Stepping up a level, what is your goal in replacing calls to malloc() and > free()? Is it any different than what SAFECode, SoftBound, or ASan do? > That's a good question. I didn't knew about SoftBound until now, so thank you for the name =). Anyway here is what I

Hi everyone, I am having troubles but this shouldn't be hard to solve for many people here. I am beginning a runtime feature for the BoundsChecking pass and I want to replace the libc malloc&free. I followed the design of AddressSanitizer (Asan) and tried to use the INTERCEPTOR macro from the interception.h file of compiler-rt library. Here is the problem. The file I modify

Dear Pierre, Stepping up a level, what is your goal in replacing calls to malloc() and free()? Is it any different than what SAFECode, SoftBound, or ASan do? Regards, John Criswell On 5/25/16 8:05 AM, Pierre Gagelin via llvm-dev wrote: > Hi everyone, > > I am having troubles but this shouldn't be hard to solve for many > people here. I am beginning a runtime feature for the

Hi, I am a final year French student doing an internship at the University of Portsmouth. As I was taking hands on AddressSanitizer I took a look at BoundsChecking (both are in the lib/Transforms/Instrumentation folder). I found nothing on it except for the LLVM Documentation and references to BaggyBoundsCheck (which is not the same project. As far as I understood it is part of the SAFECode

> On May 25, 2016, at 6:05 AM, Pierre Gagelin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi everyone, > > I am having troubles but this shouldn't be hard to solve for many people here. I am beginning a runtime feature for the BoundsChecking pass and I want to replace the libc malloc&free. I followed the design of AddressSanitizer (Asan) and tried to use the

Hi Pierre, I'm the author of the BoundsChecking pass. It's true there's little documentation about it (only mentioned in: http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#availablle-checks). You can run it with 'clang -fsanitize=bounds' or 'opt -bounds-checking'. The BoundsChecking pass, AddressSanitizer and BaggyBoundsCheck are all different code bases,

Hi, I came on an old post (2012 or 2013) where somebody used this tool with the cpp arch option. I tried to use it too but it fails because no "cpp" architecture was referenced. Still on old posts I saw that it wasn't enabled by default for cmake builds so I added the flag -DLLVM_TARGETS_TO_BUILD="cpp" and "all" but still nothing. Was it removed from LLVM?

Hi Nuno, On 22 May 2016 at 22:33, Nuno Lopes <nunoplopes at sapo.pt> wrote: > Hi Pierre, > > I'm the author of the BoundsChecking pass. > Wow, I am happily surprised to have an answer from you directly! > It's true there's little documentation about it (only mentioned in: > http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#availablle-checks). >

Hello everyone, I have noticed that there is a BoundsChecking.c under lib/Transforms/Instrumentation/. I am wondering how to use this tool and which type of bugs it targets. Are the tool provide the same functionality with Address Aanitizer? Thanks a lot -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Kevin, Thanks for your interest and for your deep analysis. Unfortunately, your approach doesn't catch all bugs and is vulnerable to an attack. Consider the following case: ...................... | ----- obj --- | | end ^ ptr ^ ^ end-of-memory The scenario is as follows: - an object is allocated in the last page of the address space - obj is byte

I am investigating changing BoundsChecking to use address-based rather than size- & offset-based tests. To explain, here is a short code sample cribbed from one of the tests: %mem = tail call i8* @calloc(i64 1, i64 %elements) %memobj = bitcast i8* %mem to i64* %ptr = getelementptr inbounds i64* %memobj, i64 %index %4 = load i64* %ptr, align 8 Currently, the IR for bounds checking

On Tuesday 26 June 2007 14:05, Reid Spencer wrote: > I think you mis-interpreted something. That's not surprising. :) > If you build with -disable-assertions you are telling whatever build > mode (Debug or Release) to not include assertions. Consequently you get > either Release-Asserts (Release minus asserts) or Debug-Asserts (Debug > minus Asserts). I was wondering if

Hi Nuno, I noticed your commits related to -fbounds-checking and have some questions. The functionality of this new phase seems to (partially?) overlap with AddressSanitizer and SAFECode, so I am curious how would you compare the two existing tools with the new one. Earlier you wrote: >> So the main idea of this new flag is not for debugging, but rather for production. >> This means

On 2/26/15 9:54 AM, Jyoti Rajendra Allur wrote: > Hello All, > I am looking at exploring what benefits SAFECode has to offer over clang S.A and llvm's instrumentation tools like memory sanitizer and address sanitizer. Are you looking for an off-the-shelf tool, or are you looking for approaches to use in your own tool? > I could come up with the following that are not provided in

Sorry, glad I'm in the right place. Before I start, I want to state that I'm a beginer and I'm trying to develop a backend by adapting an existent target to my platform. My first doubt is about the SelectionDAG and the TargetLowering class. When I use, for example: setOperationAction(ISD::ADD, MVT::i1, Promote); Is it correct to say that I'm promoting any operand used by the

http://blog.mellenthin.de/archives/2008/12/30/25c3-hangover/ says, in a writeup about the recent CCC meeting, "Sehr interessant war Squeezing Attack Traces und Stormfucker: Owning the Storm Botnet. Zuerst wurden konkrete Techniken gezeigt, wie man Malware analysieren kann. Die Zentrale Idee ist hier, statt eine Sandbox (Windows in einer VM) zu verwenden, die Requests unter Linux an Wine

Nuno, Inspired by this email thread, I spent a bit of time today looking through the implementation of BoundsChecking::instrument(..). Based on my reading of prior work, it should be possible to do these checks in two comparisons, or possibly even one if the right assumptions could be made. Could you provide a bit of background of the expected domains of Size and Offset? In particular,

Hello, As far as I know, there is no MPX pass in LLVM (though the x86-64 backend already declares MPX registers and instructions). I wonder if anyone is currently working on the LLVM pass for MPX instrumentation, similar to Pointer Checker in gcc. If yes, could anyone elaborate on the status and accessability to other researchers? And if any help is needed? Prof. Santosh Nagarakatte, the author

Thanks, indeed it was on the LegalizeDAG.cpp and the information proved very useful. I also realized that the customization, promotion or expansion will occur whenever any operand, with the same type as the type specified on the second argument (MVT) of setOperationAction function, appears. (Correct me if I'm wrong). The second doubt I have regards instruction matching. When I define a

Hi, Thanks both of you for the help. I just missed that Create function had many optional arguments... sorry for that. However my problem wasn't coming from here (IRBuilder CreateCall function still return a pointer to CallInst so I just added 2 times the call?). I didn't wanted to detail the all issue previously because I knew I had a problem with my syntax. So here's my problem: I