[cfe-dev] -fbounds-checking vs {SAFECode,ASan}

[John Criswell]

On 5/24/12 4:43 AM, Kostya Serebryany wrote:
> 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.

Nuno's original goal (described in our first set of email exchanges on 
llvm-commits) was to provide lightweight security checks to programs 
compiled by clang by using the -fbounds-checking option.  I believe the 
goal is to protect applications at run-time.

Nuno, is this correct, or did I misinterpret what you wrote?

>
> Earlier you wrote:
> >> So the main idea of this new flag is not for debugging, but rather 
> for production.
> >> This means that we won't be able to perform as many checks as
> >> AddressSanitizer,
>
> From the code (lib/Transforms/Scalar/BoundsChecking.cpp) I can 
> conclude that you add checks only if you can
> deduct the array boundaries, either from constants or from malloc() 
> parameter.
> How many run-time checks does -fbounds-checking create? Do you have 
> such statistics?
> Do you also have performance numbers?
>
> Are there any bugs that -fbounds-checking can find but {SAFECode,ASan} 
> can not?
>
> >> but the performance is supposed to be acceptable for
> >> binaries that are shipped for production.
>
> Btw, AddressSanitizer's performance *is* acceptable for production in 
> many circumstances.
>
> Why do you route all run-time checks to a single trap BB?
> I understand this as a code-side optimization, but it makes analyzing 
> the failure almost entirely impossible.
> Even if you use different traps, what is the expected user experience 
> once he/she receives the trap?

I don't think Nuno is trying to make a tool that helps diagnose memory 
safety problems.  Instead, he's trying to build a tool that prevents 
exploitation of code at run-time.  A single trap block is the correct 
approach for that goal.

-- John T.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120524/f1147a74/attachment.html>