[LLVMdev] GSOC project on KCoFI

John Criswell jtcriswel at gmail.com
Fri Mar 27 08:44:42 PDT 2015

On 3/27/15 7:34 AM, Aditya Verma IDD M Tech Computer Sc & Engg., 
IIT(BHU), Varanasi (U.P.) wrote:
> can anyone please review my proposal. I need suggestions on timeline 
> on the PNaCL improvements and also its improvements.

Just a nitpick: I prefer proposals to be in PDF format.  I find typeset 
text easier to read.

> *Project Goals:*
> The primary objective of this project is to implement stronger SFI 
> mechanism in existing kernel of KCoFI.The following are three broad 
> improvements I aim to implement in KCoFI:
>        1 .Implement a stronger call graph using libLTO tool.
>        2.To replace KCoFI's SFI instrumehntation with that found in 
> Portable Native Client (PNaCL).

As I stated in my last email, I've changed my mind about replacing the 
SFI implementation in KCoFI with the PNaCL implementation.  It makes 
more sense to protect the SVA-OS internal data structures using the 
WP-bit trick that it uses to protect the page table pages.  This should 
alleviate the need for SFI and make the implementation faster.

> CFI is a compiler based security mechanism that protects against the 
> malicious programs that hijack the flow of control of the 
> program*[1]*. KCoFI *[2]* is a security mechanism for operating system 
> kernel that extends the CFI technique to os kernel. Thus KCoFI is a 
> security mechanism that protects commodity operating systems from 
> classical control- flow hijack attacks, return-to-user attacks, and 
> code segment modification attacks.
> KCoFI uses traditional label-based protection for programmed indirect 
> jumps *[1] *but adds a thin run-time layer linked into the OS that 
> protects some key OS data structures like thread stacks and monitors 
> all low-level state manipulations performed by the OS.
> KCoFI is an LLVM based kernel. In this project I aim to undertake the 
> improvements in the KCoFI mechanism to make it stronger against ever 
> growing future attacks.
> Software Fault Isolation(SFI) is the act of separating distrusted 
> extensions that are possibly faulty.

Again, I think it's best to remove SFI and replace it with a more 
efficient mechanism.

> This project is organized as a two part project in which the first 
> part aims to implement a stronger call graph and the second part 
> integrates the SFI Instrumentation found in PNaCl(Portable Native 
> Client) to KCoFI and replace the older SFI Instrumentations.
> *Portable Native Client* extends that technology of sandboxing used by 
> Native CLlent with architecture independence, letting developers 
> compile their code once to run in any website and on any architecture 
> with ahead-of-time (AOT) translation.
> This project will make use of Software Fault Isolation(SFI) 
> Instrumentations of PNaCL and integrate them with KCoFI while 
> replacing the older SFI Instrumentations of KCoFI.
> The following is the things to do in the project:
> *1. Implementing a stronger call graph:* in this part of the project 
> the FreeBSD kernel will be compiled using the libTO tool. This will 
> involve writing patches that build to IR, use llvm-link to run LTO and 
> then link the resulting binary. This project will involve delving 
> further into the llvm bundle. It will requires modifying the CFI 
> MachineFunctionPass to support multiple labels.
> Since, KCoFI currently uses a really weak call-graph (all functions 
> and call sites are equivalence-classed), thus after compiling the 
> FreeBSD kernel with libLTO, first task to do is to improve the CFI 
> instrumentation to enforce a more accurate call graph. This 
> implementation will be done by using libLTO to compute a whole-kernel 
> call graph and then using different CFI labels for different nodes in 
> the call graph.
> It could be improved by using libLTO to compute a whole-kernel call 
> graph and then using different CFI labels for different nodes in the 
> call graph.
> A second improvement would be to remove CFI labels that are 
> unnecessary.  Any function that is only called directly does not need 
> a CFI label.  Again, to make this optimization work, a whole-kernel 
> analysis will be done via libLTO.
> Another improvement to undertake is to implement Forward Edge Call 
> graph*[5]*.

KCoFI already implements checks on indirect function calls (i.e., 
forward edges in the call graph).

> *2.Replace KCoFI's SFI instrumentation with the Instrumentation  found 
> in Portable Native Client (PNaCL):
> *
> The PNaCL implementation should be much better than KCoFI's. PNacl and 
> NaCL both are open source.The SFI approach NaCl takes expects a single 
> sandbox per process, which doesn't seem very suitable to kernel use. 
> It can be made to support multiple sandboxes in the same address 
> space, which is the work that I will undertake as a part of the project.
> This project will require modifying the CFI MachineFunctionPass and 
> using either the LLVM CallGraphAnalysis pass or the DSA CallGraph 
> pass.  It will also require modification of the low-level KCoFI 
> run-time library (i.e., the implementation of the SVA-OS instructions, 
> as some of them need to do CFI checks).

To be clear, KCoFI does not need to sandbox applications.  It only needs 
to sandbox the kernel from the SVA-OS run-time library (also called the 
KCoFI run-time library in the KCoFI paper).  There is no per-application 
sandbox in KCoFI.

> *Timeline and Roadmap:*
> Since it is a big project and I will be using the existing code of 
> KCoFI I will be going ahead with the Iterative Enhancement model of 
> Software Development Process
> *Week 1:*Discussion with my mentor on documentation style and the code.

This step will not take a week.  If selected, we'll have an initial 
meeting and have you begin work within the first week.

> *Week 2 to Week 3:* Writing the patches that build to IR and use llvm- 
> link to run LTO with FreeBSD
> *Week 4 to Week 6:* Compiling the kernel with libLTO tool. In this 
> week I will write the methods to build a strong call graph.

You should restate this to say that you'll modify the CFI 
instrumentation pass in weeks 4, 5, and 6.  I would allot 3 weeks to 
improving the call graph.

> *Week 7:* Testing the call graphs with proper benchmarking.

What does "testing the call graphs with proper benchmarking" mean?

> *Week 8 to Week 9:* using the PNaCl and NaCL SFI techniques and 
> implementing them in the kernel.

You should take 2-3 weeks to modify KCoFI to alleviate the current SFI 
pass.  Take out Week 7 to make room if necessary since this will be a 
significant job.

> *Week 10:* using the NaCl to support multiple sandboxing in same 
> address space for for multiple processes in an os kernel.

Again, you only need one sandbox.  KCoFI uses sandboxing to keep the 
kernel from accessing SVA-OS internal data structures.  Also, you should 
not use SFI; you should use the the WP-bit trick that KCoFI uses to 
protect page table pages.

> *Week 11:* testing the new sandboxing techniques together with the 
> previous techniques of stronger call graph imlemntation with proper 
> benchmarking of the compile time.
> *WEEK 12:* Evaluating the performance of the improvements.

My experience suggests that performance evaluation will take two weeks.

> *Criteria of Success:*
> 1. Newer stronger call graph implementation. Evaluation done using 
> proper benchmarking.
> 2.Implmentation of SFI Instrumentation of PNaCl,
> Thus by the end of the summer improving the call graph, replacing the 
> SFI instrumentation, and evaluating the performance will be the work 
> that I will complete.
> *Brief Bio:*
> I am a third year undergraduate in Computer Science and Engineering. 
> My interests lie in Computer Architecture and Operating System. I like 
> working with the machinistic aspects of computer science. My rigorous 
> programming experience has spanned across fields such as Database 
> Management System, Operating Systems, Networking , Artificial 
> Intelligence and Machine Learning. I see myself as a hardworking and 
> sincere, at the same time passionate about building newer software. I 
> also have experience programing the Microprocessor 8085 and 8086.
> I am proficient in C and C++.

You should provide information on previous projects that you've 
completed successfully.  This will make your claims about your 
experience far more concrete.


John Criswell

John Criswell
Assistant Professor
Department of Computer Science, University of Rochester

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

More information about the llvm-dev mailing list