GSOC project on KCoFI

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 #1 and #3 that are improving the call graph and porting the KCoFI SFI methods to the ones used in NaCl and PNaCl. It seems to me the community is more interested towards the SFI methods.

If the course of the project permits I may also contribute to the fourth improvement that you mentioned.

Earlier I mentioned three modifications to improve the KCoFI project.

After the valuable feedback from the members I am deciding to go ahead with

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

  2. 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. I will be trying to integrate the Forward Edge Call Graph techniques also in this project.

  3. porting the newer version of FreeBSD kernel to SVA-OS instruction set.

As a brief timeplane

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: Compiling the kernel with libLTO tool. In this week I will write the methods to build a strong call graph.

Week 5: Testing the call graphs.

Week 6-7: using the PNaCl and NaCL SFI techniques and implementing them in the kernel.

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

Week 9: testing the new sandboxing techniques together with the previous techniques of stronger call graph imlemntation with proper benchmarking of the compile time.

Week 10-11: Porting the newer version of the FReeBSD kernel to SVA-OS instruction set.

WEEK 12: testing of the complete project with real world malicious programs.

What exactly should i do in the porting to the SFI techniques of PNacl and Nacl. Will it sandbox each process using its call graph or will it sandbox some unprivileged processes making the use of capabilities?

How much will the project involve writing into the llvm code bundle?

Should I apply in llvm or in FreeBSD? If I apply in FreeBSD then I believe the project of porting the kernel to arm architecture will be of more use there. Or should I submit proposals to both the organizations?

I just want to ask how should I try to convince other mentors that this project will be useful for the llvm community as a whole?

The things that I am not able to write in my proposal are how to give strong reasons to convince the mentors that this project will be useful for the llvm community as a whole. Also I need some more suggestions about the timeline and the roadmap if you can help.

Sorry for being late I was busy with my mid semester examinations.
And unfortunately while installing FreeBSD on my system something went wrong with the EFI file system and my entire HDD and windows was lost.

I will be uploading the proposal soon.

Regards
Aditya Verma
Junior Undergraduate
IDD Computer Sc & Engg
IIT(BHU), Varanasi(UP)

You will either use libLTO or you will use opt/llvm-link to do whole-program analysis on the kernel. As such, you will do one or the other but not both. My preference would be to try a version of libLTO with all optimizations disabled first and then fall back to using opt/llvm-link/llc if that fails. I also think that extending the current KCoFI CFI implementation with stronger call graph support will take more than a week. It requires modifying the CFI MachineFunctionPass to support multiple labels. KCoFI only needs to support a single “sandbox,” so to speak. The KCoFI run-time library has data structures which the kernel must not overwrite. There are no other per-process “sandboxes” that KCoFI needs to implement. I’m also thinking that, for x86, KCoFI should replace the SFI instrumentation with the WP-bit mechanism that it uses to protect page table pages. This should be far more efficient than SFI instrumentation. I don’t think the current KCoFI implementation is robust enough to compile an entire FreeBSD kernel (otherwise, I would have run it as a benchmark for the paper). You should evaluate the performance using microbenchmarks and the networking benchmarks used in the KCoFI paper (which should still work after you’ve made your changes). I wouldn’t add this to the timeline. If you’re making significant changes to the implementation, then I’d stick with the current FreeBSD 9.0 implementation I would not evaluate the prototype this way. Testing exploits is time consuming and non-conclusive. I think testing the security efficacy of the prototype is beyond the scope of GSoC; I’ll be having a student of my own begin work on new methods of evaluating defenses against code-reuse attacks. I suspect that, by the end of the summer, merely improving the call graph, replacing the SFI instrumentation, and evaluating the performance will be enough work. If you’ve read and understood the KCoFI paper, then you should know the answer to this question. The 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). That’s a good question, but I’m afraid I don’t have a good answer. My impression (based on very limited data) is that the FreeBSD community is a bit more open to this project than the LLVM community. I think the benefit to the LLVM community is that we’ll have an operating system kernel that is better hardened against control-flow hijack attacks, and it’s implementation will rely upon LLVM. Please include a CV or resume in your proposal. One of the things a strong proposal will do (both with a CV/resume and with text within the proposal) is argue that you’re the right person for the job. Regards, John Criswell

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

Can anyone also review it on my dashboard???

Just a nitpick: I prefer proposals to be in PDF format. I find typeset text easier to read. 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. Again, I think it’s best to remove SFI and replace it with a more efficient mechanism. KCoFI already implements checks on indirect function calls (i.e., forward edges in the call graph). 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. This step will not take a week. If selected, we’ll have an initial meeting and have you begin work within the first week. 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. What does “testing the call graphs with proper benchmarking” mean? 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. 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. My experience suggests that performance evaluation will take two weeks. 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