[LLVMdev] GSOC project on KCoFI

Thu Mar 26 17:15:11 PDT 2015

On 3/26/15 5:56 PM, Aditya Verma IDD M Tech Computer Sc & Engg., 
IIT(BHU), Varanasi (U.P.) wrote:
> 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.

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.

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

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.

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

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

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

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

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

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.

>
> 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?

If you've read and understood the KCoFI paper, then you should know the 
answer to this question.

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

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

> 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?

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

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.

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

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

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

-- 
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/20150326/f52958b4/attachment.html>