search for: svaing

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>

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>

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

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

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

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

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

Sandro Magi wrote: > 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? > To be honest, while I understand your questions, I do not understand the context in which you are asking them. Are you asking

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.

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

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:

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

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

On 6/6/07, Sandro Magi <naasking at gmail.com> wrote: > 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 > >

If you're one of the people who has cvsup'd to 4.8-stable since August 8th and you've since begun to experience panics on a previously stable system, please apply the attached patch and see if your previous stability has been restored. Please tell me your results. Thanks, Mike "Silby" Silbersack -------------- next part -------------- diff -u -r

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

We have a research project that is developing a Secure Virtual Architecture using LLVM as the instruction set, and implementing via a VM which we call a Secure Virtual Machine. The memory safety foundations of this work are based on Dinakar Dhurjati's thesis and publications: http://llvm.org/pubs/ SVA is at a very preliminary stage but some slides about it are attached.