[LLVMdev] GSOC:Control Flow integrity for kernal

John Criswell jtcriswel at gmail.com
Tue Mar 17 00:43:51 PDT 2015

On 3/16/15 11:51 PM, Aditya Verma IDD M Tech Computer Sc & Engg., 
IIT(BHU), Varanasi (U.P.) wrote:
> Hi
> I want to pursue a project based to improve the existing KCoFI method 
> which is the Control Flow integrity method for commodity os. Since 
> KCoFI is a llvm based project I plan to undertake the project to 
> improve the existing KCoFI method. Following are the improvements that 
> I want to pursue:

You might want to include a link to the KCoFI paper for those who do not 
know what KCoFI is.

> 1. To improve the call graph used in KCoFI. Implement a stronger call 
> graph.
> 2. Port the KCoFI to another architecture such as ARM or x86-32.
> 3 .To replace KCoFI's SFI instrumentation with that found in Portable 
> Native Client (PNaCL)

A fourth option would be to update the KCoFI code to the latest version 
of FreeBSD.  That would require updating the LLVM passes to work in a 
newer version of LLVM and porting a newer version of the FreeBSD kernel 
to the SVA-OS instruction set.

Reviewing the three improvements that you listed, I think that doing all 
three during a single GSoC would be too much work, namely because 
improvement #2 would be a project in and of itself. Improvements #1 and 
#3 might be doable together in a single summer (depending on how things go).

For improvement #1, you'll need to enable libLTO when compiling the 
FreeBSD kernel (in order to compute a whole-program call graph). You 
should try to compile the FreeBSD kernel with the -flto option to see if 
it's going to work.  If it doesn't, then your GSoC project would devolve 
into getting LLVM to compile the FreeBSD kernel with the -flto option.

For improvement #2, I would not do x86-32.  The CFI code already works 
for 32-bit x86, and so there's not a lot of LLVM work to do for x86-32; 
all of the work would be to get the SVA-OS layer working (which should 
be easy as we have a 32-bit implementation upon which the 64-bit 
implementation is based).  You should also specify whether you're 
porting just the CFI instrumentation, the SVA-OS protections, or both.

If you do improvement #3, you should first very that PNaCL is 
open-source.  I think it is, but I haven't checked, so you should do 
that. :)

> Can anyone review my idea for the projects? I believe pursuing a 
> project on KCoFI will be worth because it is the only Control Flow 
> Integrity protection for commodity operating systems which does not 
> uses any expensive memory safety. I believe this project will have a 
> wide scope for the future.

I'm curious as to whether others in the LLVM community are interested in 
this GSoC project.  I believe someone mentioned a CFI project on 
specialized hardware (the CHERI machine?), but I can't find the email on it.


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

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

More information about the llvm-dev mailing list