[LLVMdev] Proposal for GSOC : KCoFI

[Kenneth Adam Miller]

Hey I'd love to contribute to this, but I think it's incredibly ambitious
for a single summer.

On Fri, Mar 27, 2015 at 10:54 AM, Aditya Verma IDD M Tech Computer Sc &
Engg., IIT(BHU), Varanasi (U.P.) <aditya.verma.cse12 at iitbhu.ac.in> wrote:

> can anyone please review my proposal. I need suggestions on timeline on
> the PNaCL improvements and also its improvements.
>
> *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).
>
> 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.
>
> 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]*.
>
>
> *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).
>
> *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.
> *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.
> *Week 7:* Testing the call graphs with proper benchmarking.
> *Week 8 to Week 9:* using the PNaCl and NaCL SFI techniques and
> implementing them in the kernel.
> *Week 10:* using the NaCl to support multiple sandboxing in same address
> space for for multiple processes in an os kernel.
> *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.
>
> *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++.
>
>
> *References:*
> [1] M. Abadi, M. Budiu, U. Erlingsson, and J. Ligatti, “Control-flow
> integrity principles, implementations, and applications,” ACM Trans. Inf.
> Syst. Secur. , vol. 13, pp. 4:1–4:40, November 2009.
> [2] KCoFI: Complete Control-Flow Integrity for Commodity Operating System
> Kernels
> [3] M. Zhang and R. Sekar, “Control flow integrity for COTS binaries,” in
> Proceedings of the 22nd USENIX conference on Security , ser. SEC’13.
> Berkeley, CA, USA: USENIX Association, 2013, pp. 337–352.
> [4] J. Criswell, A. Lenharth, D. Dhurjati, and V. Adve, “Secure Virtual
> Architecture: A Safe Execution Environment for Commodity Operating
> Systems,” in Proc. ACM SIGOPS Symp. on Op. Sys. Principles
> [5] Caroline Tice , Tom Roeder , Peter Collingbourne , Stephen Checkoway
> , Úlfar Erlingsson , Luis Lozano , Geoff Pike, Enforcing forward-edge
> control-flow integrity in GCC & LLVM, Proceedings of the 23rd USENIX
> conference on Security Symposium, p.941-955, August 20-22, 2014, San Diego,
> CA
> <http://dl.acm.org/citation.cfm?id=2671285&CFID=492903293&CFTOKEN=22797912>
> Regards
> Aditya Verma
> Junior Undergraduate
> IDD Computer Sc & Engg
> IIT(BHU), Varanasi(UP)
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150327/005cade5/attachment.html>