[LLVMdev] GSOC project on KCoFI

[John Criswell]

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.

Regards,

John Criswell

-- 
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
http://www.cs.rochester.edu/u/criswell

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