similar to: [LLVMdev] How about state of SVA

Hello, Is the SVA codebase publically available, and if so, where can I find it? Thanks. -- gregory malecha -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110627/4f816aa6/attachment.html>

I would not have expected this upon implementing sieve. And I really need to get around this limitation. LDA has no problem writing to these large mbox files. Why does sieve have a problem with them? This is very odd. May 10 17:45:04 greer dovecot: deliver(stan): write() failed with mbox file /home/stan/mail/1-Debian-Users: File too large May 10 17:45:04 greer dovecot: deliver(stan): write()

Hi all, I do a little work on the Glasgow Haskell Compiler (GHC) which uses LLVM for the backend when compiling for Arm and some other targets. The reason I am posting to this list is that a GHC compiled program (using the LLVM backend) is getting an illegal instruction exception on the this instruction: ldr r0, [r0] According to the Arm archtecture manual:

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

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

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

Hi, I ran into a problem when running DSA on Linux kernel (the Kernel version I used is 2.4.31). The analysis was aborted when it tried to do DSNode::mergeTypeInfo on some data structure in the kernel. I have filed a bug report at http://llvm.org/bugs/show_bug.cgi?id=1656. My question is what version of Linux kernel LLVM has been tested on successfully? To run DSA analysis, should I use the

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

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.

On 12/23/15 2:09 AM, Russell Wallace wrote: > On Tue, Dec 22, 2015 at 10:55 AM, John Criswell <jtcriswel at gmail.com > <mailto:jtcriswel at gmail.com>> wrote: > > You could conservatively assume that any function that has its > address taken has a pointer to it that escapes into memory or > external code. > > > Right, that's what I'm

Hi I want to pursue a project based to improve the existing KCoFI method which is the Control Flow integrity method for commodity os. Since KCoFI is a llvm based project I plan to undertake the project to improve the existing KCoFI method. Following are the improvements that I want to pursue: 1. To improve the call graph used in KCoFI. Implement a stronger call graph. 2. Port the KCoFI to

2015-09-01 11:38 GMT+08:00 John Criswell <jtcriswel at gmail.com>: > On 8/31/15 10:43 PM, 慕冬亮 via llvm-dev wrote: > > I want to create an experiment to show the effectiveness of cfi : > For example , > I first need a program with vulnerability so that we can hijack its > control flow; > > then I enforce cfi of llvm and we can't hijack its control flow. > >

On Mon, Apr 28, 2014 at 10:30 PM, John Criswell <criswell at illinois.edu>wrote: > Dear Petsas, > > For analyzing indirect function calls, your best bet is probably to use > the CallGraph analysis pass that is part of DSA. DSA is included in the > poolalloc code; you can get directions on downloading poolalloc from the > SVA web page:

On 6/5/07, John Criswell <criswell at cs.uiuc.edu> wrote: > > To be honest, while I understand your questions, I do not understand the > context in which you are asking them. Are you asking if LLVM provides > any facilities to provide these protections, or are you asking if we've > added any special features to LLVM (or to SVA; our research work based > on LLVM) to

Dear all, I would like to keep track of all the indirect calls that may caused from function pointers inside a program. I need this in order to be able to construct the control flow graph of all the indirect calls, that is which function is legal to call another function. Is there a module that implements this functionality in llvm? If not, is there a way to do it? Maybe through implementing a

Hi all, I'm trying to generate whole program bitcode files for linux kernel and do interprocedural analysis on kernel. I use llvmlinux to compile kernel with clang and generate a bunch of bitcode files successfully. I need to link all these bitcode files together into a single bitcode file, so that I can run whole program analysis. Should I use libLTO to link all these bitcode files

Hi In my previous mail I mentioned the project on KCoFI( the control FLow integrity methods for commodity hardware http://sva.cs.illinois.edu/pubs/KCoFI-Oakland-2014.pdf ). Will it be more helpful to the community if I do the improvements number #1 and #3 mentioned in my previous mail to the mailing list or if i try to port it to arm architecture? I have decided to go ahead with the improvements

Dear All, To add to this, you can find examples of inserting NOPs for X86 in the CFI pass originally written at Lehigh University that we ported to 64-bit X86 for SVA: https://github.com/jtcriswell/SVA/blob/master/llvm/lib/Target/X86/X86CFIOptPass.cpp Alternatively, you could use an InlineAsm call at the LLVM IR level (which I think would be easier to implement). Regards, John Criswell On

I want to create an experiment to show the effectiveness of cfi : For example , I first need a program with vulnerability so that we can hijack its control flow; then I enforce cfi of llvm and we can't hijack its control flow. Do you have any advice for me? - mudongliang -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Thu, Oct 20, 2011 at 2:37 AM, Shea Levy <shea at shealevy.com> wrote: >. The > (probably impossible) end-goals to this project would be a) that every > program which passes its checks would be as safe to run in kernel mode > with full memory access as it would be in user mode That would be a very useful thing to have for embedded systems. Some such as uCLinux run ports of