similar to: Runtime interception: design problem

> 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

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 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, After spending 2 months on LLVM generally speaking and more specifically on security passes (ASan, SAFECode, BoundsChecking) I wanted to know if there were an available implementation of strictly fat-pointer based approach to enforce bounds? If not, I wanted to implement one. I think it is interessant to have such a tool available even if there are better designs (SoftBound does

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

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). >

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,

I think this issue is that we were not using the INTERCEPTOR macros to define these functions. The following patch seems to work for me to get the build linking again, however, I cannot test -- when I run check-asan, I get: 2> lit.py: lit.common.cfg:59: fatal: Invalid llvm_tools_dir config attribute: 'E:/llvm/2013/$(Configuration)/bin' ~Aaron On Thu, Oct 23, 2014 at 1:20 PM, Aaron

On Thu, Oct 23, 2014 at 2:46 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > 2014-10-23 11:34 GMT-07:00 Aaron Ballman <aaron at aaronballman.com>: >> On Thu, Oct 23, 2014 at 2:24 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: >>> I don't think this is the right approach. >>> >>> Currently we intentionally define malloc etc

On Thu, Oct 23, 2014 at 2:24 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > I don't think this is the right approach. > > Currently we intentionally define malloc etc without changing the > names and (when stuff works ok) the linker just links all the mem > allocator calls with calls to our RTL. This is kind of a link-time > interception. How could that work

On Thu, 2019-01-24 at 19:58 +0100, Dimitry Andric via Release-testers wrote: > On 24 Jan 2019, at 01:49, Hans Wennborg via Release-testers <release-testers at lists.llvm.org> wrote: > > > > 8.0.0-rc1 was just tagged (from the branch at r351980). > > > > It took a little longer than planned, but it's looking good. > > > > Please run the test

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. I could come up with the following that are not provided in ASAN/MSAN/Clang S.A -> dangling pointer error and detection -> crashes in system libraries due to security vulnerabilities. In the process, I wanted to run the

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

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:

On Thu, Jun 16, 2011 at 11:00 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jun 16, 2011, at 1:27 AM, Kostya Serebryany wrote: > > Hello again, > > The tool we announced 1.5 months ago has matured quite a bit. > In addition to heap out-of-bound and use-after-free bugs it also finds > stack overruns/underruns. > AddressSanitizer is being actively used by

Hello, even though the study of Intel MPX took much longer than expected, we have finally finished it. Currently, it is published in two formats: * as a technical report: https://arxiv.org/abs/1702.00719 * and as a webpage: https://intel-mpx.github.io/ This work contains evaluation of MPX from perspectives of performance (Phoenix, PARSEC, and SPEC benchmark suites), security (RIPE and found

On Thu, Oct 23, 2014 at 3:38 PM, Aaron Ballman <aaron at aaronballman.com> wrote: > On Thu, Oct 23, 2014 at 2:57 PM, Aaron Ballman <aaron at aaronballman.com> wrote: >> On Thu, Oct 23, 2014 at 2:46 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: >>> 2014-10-23 11:34 GMT-07:00 Aaron Ballman <aaron at aaronballman.com>: >>>> On Thu, Oct

On 10 October 2014 21:31, Jonathan Roelofs <jonathan at codesourcery.com> wrote: > Sounds like an arm-thumb interworking veneer, generated by the linker... the > real function should be called 'asan_handle_no_return' (with some number of '_' > prefixing it. I don't remember how many get added). It is a veneer which has just a jump and a word after it, which

Dmitrii, all, Please note, that GCC 5.3 had a significant update to the MPX code quality - please, use this version as reference. Regards, Sergos On Tue, Feb 9, 2016 at 12:49 AM, Kostya Serebryany via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Feb 4, 2016 at 10:40 AM, Kostya Serebryany <kcc at google.com> wrote: > >> >> >> On Thu, Feb

compiler-rt libs must be built with /MT, so the MSVS build is doing the wrong thing here. 2014-10-23 12:52 GMT-07:00 Aaron Ballman <aaron at aaronballman.com>: > On Thu, Oct 23, 2014 at 3:42 PM, Aaron Ballman <aaron at aaronballman.com> wrote: >> On Thu, Oct 23, 2014 at 3:38 PM, Aaron Ballman <aaron at aaronballman.com> wrote: >>> On Thu, Oct 23, 2014 at 2:57