[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.
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/20150317/8fb24640/attachment.html>
More information about the llvm-dev
mailing list