[LLVMdev] GSOC project on KCoFI
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**. KCoFI ** 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 * *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
> 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
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
> *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.
Department of Computer Science, University of Rochester
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev