similar to: [LLVMdev] secure virtual architecture / safecode

John, We (more accurately, John Criswell and Brice Lin) are working on a debugging version of SAFECode right now, which should be robust enough to play with soon. What kinds of embedded codes do you have in mind? One of our goals has been to minimize or even eliminate run-time checks for embedded code that meets certain restrictions. You can see the following paper for more details:

Hi Vikram, I think it's worth continuing to discuss this on-list. I'm interested in different kinds of embedded software, but specifically in TinyOS applications. > We (more accurately, John Criswell and Brice Lin) are working on a > debugging version of SAFECode right now, which should be robust enough > to play with soon. This is great to hear. I know the SAFECode paper

I understand. They only way you can keep the code bloat at a few percent or less is to aggressively eliminate nearly all run-time checks. We haven't measured our code size increases but if you have any codes to send us, we can try to get you some preliminary numbers. We do have a static array bounds checking algorithm based on the Omega integer programming library, but it is not

yiqiuping1986 wrote: > Hi， John Criswell！ > You have said to me that SAFECode had not been maintained for several > years, Just to clarify, SAFECode *has* been and *is* maintained (primarily by me). The release_26 branch in the SVN repository works with LLVM 2.6, and mainline is working (with some regressions) with the upcoming LLVM 2.7. You can subscribe to the SVA Commits mailing list

Dear All, We now have two new mailing lists for SAFECode: 1) svadev: This mailing list is for discussion on SAFECode. Questions and comments about using SAFECode as well as development conversation on SAFECode can go here. 2) sva-commits: This mailing list gets email for all SVN commits made to SAFECode. -- John T.

Török Edwin wrote: > [snip] > > I applied the attached patch to make it compile on my box (Debian > x86_64), only to find out that x86_64 is not supported :( > This architecture is not supported by the pool allocator! > Aborted > Thanks for the patch. What options do I give to the patch command to apply it to the source code? Although there's no documentation about

Hi， John Criswell！ You have said to me that SAFECode had not been maintained for several years, now I have submitted my proposal for updating the SAFCode project to the new LLVM APIs. If you are still interested in the topic and willing to guid my project, I will be very happy. Now I'm waiting for you comments. Here is my proposal:

On 9/9/11 1:08 PM, Jack Howarth wrote: > Are there any plans to add CMake support to the build of > SAFECode? No, there are no current plans to do so. Is not having CMake support a show-stopper for you? I imagine adding support for it would be straightforward. > Also are there any current instructions for building > llvm/clang with SAFECode support from current svn? Yes.

Dear All, I've developed a patch for mainline LLVM that integrates parts of the SAFECode memory safety compiler (http://sva.cs.illinois.edu) into LLVM. The patch includes transforms that add run-time safety checks to loads and stores and GetElementPtr instructions, a run-time library that implements the checks, a transform that enhances the run-time checks with source file debugging

John, The release source code (sc-main.tar) won't compile cleanly under Debian6-i386 (gcc/g++: 4.4.5). The compiler back trace is attached. Please fix it/them and repost. Or, 64b system is a requirement? Thank you Chuck llvm[4]: Compiling TypeRuntime.cpp for Release+Asserts build (PIC) cc1plus: warnings being treated as errors

Dear All, We have a new release of Clang with SAFECode technology for detecting memory safety errors. Memory safety checking (SAFECode for short) can be turned on with a single command line switch to clang/clang++. The SAFECode techniques do not change the behavior of the clang/clang++ compilers in any way when the switch is turned off, so this can be used as a drop-in replacement for

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

Hi, My apologies for the trouble. I've disabled building DynamicTypeChecks for now (r138224) and now it builds cleanly on 32bit for me here. As for SAFECode support for 32bit vs 64bit, I believe 32bit should work just fine although I haven't personally tested this. Let me know if you have any further issues/questions. ~Will On Sun, Aug 21, 2011 at 9:26 AM, Chuck Zhao <czhao at

On 4/3/13 8:21 AM, Marcelo Sousa wrote: > I am interested in type-based verification of LLVM IR in the areas of > certified compilation and software Can you explain what you mean by type-based verification? Do you mean that you want to use a set of typing rules to perform verification, or do you mean something else? > verification. It seems to me that the LLVM IR type system is

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

Are there any plans to add CMake support to the build of SAFECode? Also are there any current instructions for building llvm/clang with SAFECode support from current svn? Jack

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 noticed your commits related to -fbounds-checking and have some questions. > The functionality of this new phase seems to (partially?) overlap with > AddressSanitizer

John Regehr wrote: > Qiuping, > > Have you looked at what has already been done? I would expect that taking > previous work such as this: > > http://llvm.org/pubs/2006-05-24-SAFECode-BoundsCheck.html > > and integrating into current LLVM would be a better idea than starting > over. > This code is publicly available from the SAFECode project (see

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

How about state of SVA (Secure Virutal Archtecture)? It seems there is no any demo or prototype produced. Cheers, Liu Jian ---- email to: gjk.liu at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100420/e8dc1b16/attachment.html>