similar to: [LLVMdev] GSoC proposal: Common memory safety instrumentation and optimization passes for LLVM

I'd like some similar work to be done, although I view it a bit differently. This might be a separate analysis pass that knows nothing about ASAN or SAFECode and appends metadata nodes to memory access instructions saying things like - this access can not go out of buffer bounds - this access can not touch free-ed memory - this access can not participate in a race - this read

On 4/6/12 12:50 AM, Kostya Serebryany wrote: > I'd like some similar work to be done, although I view it a bit > differently. > This might be a separate analysis pass that knows nothing about ASAN > or SAFECode > and appends metadata nodes to memory access instructions saying things > like This is a good idea but is the wrong way to implement the idea. LLVM passes are

On Fri, Apr 6, 2012 at 7:50 AM, John Criswell <criswell at illinois.edu> wrote: > On 4/6/12 12:50 AM, Kostya Serebryany wrote: > > I'd like some similar work to be done, although I view it a bit > differently. > This might be a separate analysis pass that knows nothing about ASAN or > SAFECode > and appends metadata nodes to memory access instructions saying things

On 3/30/12 1:08 PM, Raphael Ernani Rodrigues wrote: > Dear LLVMers, > > My name is Raphael Ernani, and I am doing my MsC at the Federal > University of Minas Gerais, Brazil. I have been using LLVM for a > while, and I would like to participate in this year's Summer of Code. > One particular idea, in your "open projects" page caught my eye, and I > decided to

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

Dear LLVMers, My name is Raphael Ernani, and I am doing my MsC at the Federal University of Minas Gerais, Brazil. I have been using LLVM for a while, and I would like to participate in this year's Summer of Code. One particular idea, in your "open projects" page caught my eye, and I decided to write a proposal about it. The line that I liked in the page was "Create an LLVM

On 5/24/12 5:41 AM, Duncan Sands wrote: > Hi Kostya, I'm also curious to know where Nuno is going with this, and the > details of his design. I'm worried he might be reinventing the wheel. I'm > also worried that he may be inventing a square wheel :) I believe Nuno's goal is to prevent run-time exploitation of software. Nuno, please correct me if I'm wrong. And

On Fri, Mar 30, 2012 at 11:49 AM, John Criswell <criswell at illinois.edu>wrote: > On 3/30/12 1:08 PM, Raphael Ernani Rodrigues wrote: > > Dear LLVMers, > > My name is Raphael Ernani, and I am doing my MsC at the Federal > University of Minas Gerais, Brazil. I have been using LLVM for a > while, and I would like to participate in this year's Summer of Code. >

On Thu, May 24, 2012 at 9:23 PM, John Criswell <criswell at illinois.edu>wrote: > On 5/24/12 5:41 AM, Duncan Sands wrote: > > Hi Kostya, I'm also curious to know where Nuno is going with this, and > the > > details of his design. I'm worried he might be reinventing the wheel. > I'm > > also worried that he may be inventing a square wheel :) > >

On 1/24/12 3:36 PM, Kostya Serebryany wrote: > > > On Tue, Jan 24, 2012 at 1:08 PM, John Criswell <criswell at illinois.edu > <mailto:criswell at illinois.edu>> wrote: > > On 1/24/12 2:31 PM, Duncan Sands wrote: > > Hi Kostya, > > As far as I can see the C and C++ standards are not > relevant. ASAN works on >

On 02/25/2014 04:50 PM, John Criswell wrote: > > I think a more interesting idea would be to use LLVM to perform > instrumentation and then to use Valgrind to instrument third-party > libraries linked into the program. > > What I'm imagining is this: Let's say you instrument a program with > SAFECode or Asan to find memory safety errors. When you run the program >

________________________________ From: Kostya Serebryany [kcc at google.com] Sent: Wednesday, December 28, 2011 2:46 PM To: Criswell, John T Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] load widening conflicts with AddressSanitizer On Wed, Dec 28, 2011 at 12:40 PM, Criswell, John T <criswell at illinois.edu<mailto:criswell at illinois.edu>> wrote: Dear All, I think adding

Dear LLVMers, I wrote a new proposal, to improve the static array bounds checking in SAFEcode, as follows: Improving static array bounds checking in SAFEcode ================================================== Objective --------- the main objective of this project is to improve the static array bounds checking engine used in SAFECode. It was written after the open project at

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, [resurrecting an old mail thread about AddressSanitizer false positive caused by load widening] Once the Attribute::AddressSafety is set by clang (a separate patch), fixing this bug may look as simple as this: --- lib/Analysis/MemoryDependenceAnalysis.cpp (revision 148708) +++ lib/Analysis/MemoryDependenceAnalysis.cpp (working copy) @@ -323,6 +323,14 @@

On Tue, Jan 24, 2012 at 1:08 PM, John Criswell <criswell at illinois.edu>wrote: > On 1/24/12 2:31 PM, Duncan Sands wrote: > >> Hi Kostya, >> >> As far as I can see the C and C++ standards are not relevant. ASAN >>> works on >>> LLVM IR, not on C or C++. Lots of different languages have LLVM >>> frontends. I >>>

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

Dear All, I think adding metadata and expecting transforms to repect it is a bad idea. It is just too easy for someone who does not know about the metadata to add a transform that ignores it. As for SAFECode, I think we have one of several options for handling load-widening. The most obvious one is to have a pass that just boosts the allocation size of any alloca with an align 16 attribute;

Hi John and All, Thank you for the your inputs,we tried running Safecode with Liblto on our code base few weeks back,I'm very sorry to say this that we feel that safecode is not so stable and output is not so informative ,Please correct us if i'm wrong here. Thanks Again. ~Umesh On May 25, 2012 7:54 PM, "John Criswell" <criswell at illinois.edu> wrote: > On