similar to: [LLVMdev] Updating Users.html

SVA/safecode looks interesting. Is it available to play with? I grepped for strings such as "sva" "secure" "safecode" in the LLVM source tree and didn't find anything, nor did I see obvious links to implementations from the project web pages. In the short term, questions I'd be interested in answering are: What happens when embedded codes that I care

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

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.

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:

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

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

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

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

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

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.

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

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

I am interested in type-based verification of LLVM IR in the areas of certified compilation and software verification. It seems to me that the LLVM IR type system is rather informal in the sense that there is no paper with a proper formalization of the type rules, and for example, a proof of soundness for well-formedness of the code. I would like to know if you are aware of any work in this

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

SVA looks very promising. It would be great to be able to run unmodified C safely! However, it does not seem to address my original question: how can I ensure that code cannot DoS either the memory subsystem, or the CPU? In my proposal, I could execute said code in a concurrent process with a memory quota. How would SVA address that problem? Sandro On 6/2/07, Vikram S. Adve <vadve at

(Note to self: learn to scan the full digest for later messages in a thread before replying to an earlier message.) Ed, Your reply to John answered some of my questions, but not all, and raised a new one: > Maybe I should have been a bit clearer; we're really interested in full > memory and type safety. We want to harden the system against memory > corruption vulnerabilities.

Hi all, If it's not the right place to ask, please forgive me. Currently I'm working on a new operating system concept, called "Om". The first feature would be Android-like apps, coming in *.opk files that would contain all needed resources and source-code expressed in LLVM-IR assembly language. http://sett.com/openminded-os/uid/88508 How does it sound ? Julien