[LLVMdev] GSOC:Control Flow integrity for kernal

[JF Bastien]

On Tue, Mar 17, 2015 at 1:39 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk
> wrote:

> On 17 Mar 2015, at 09:43, John Criswell <jtcriswel at gmail.com> wrote:
> >
> > 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).
>
> ARMv8 is probably the most interesting other target, though it's currently
> quite immature in FreeBSD.  Andy Turner is working on the port.
>
> > 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.
>
> Currently the FreeBSD base system doesn't include an LTO-capable linker,
> but we do have some patches that build to IR, use llvm-link to run LTO and
> then link the resulting binary.  We've used this in the SOAAP and TESLA
> work.
>
> [With my FreeBSD Core Team hat on] Note that for accepting this upstream
> in FreeBSD, we would need a story for how it works with loadable kernel
> modules.  This is not insurmountable (you can do NaCl-style verification on
> the binary before loading, it's a few months since I read the KCoFi paper
> and so I'm not 100% sure if it would be similar).
>
> > 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.
> :)
>
> PNaCl is open source (though didn't look very easy to separate from the
> Chromium source tree).  PNaCl doesn't do sandboxing itself though, it
> delegates it to NaCl.  It's not clear that NaCl could be used for a kernel
> without a fairly significant amount of work.
>

PNaCl is open source and can be checked-out and build with the following
instructions:

https://sites.google.com/a/chromium.org/dev/nativeclient/pnacl/developing-pnacl


But indeed PNaCl delegates to NaCl. 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, but
it doesn't currently "just work".

I recommend looking at:
 - The work Tom Roeder recently did in LLVM (it was recently deeleted from
the code base).
 - The work David Brazdil did in PNaCl called MinSFI to do compiler-based
sandboxing.
 - Peter Collingbourne's current sandboxing work in LLVM.

The key difference between NaCl's approach and compiler-based sandboxing is
that you don't need to trust the entire compiler with the NaCl approach:
you "just" need to disassemble the final executable and inspect each bundle
to prove that the program doesn't escape the sandbox. NaCl's approach is
more intrusive and has a bigger performance impact.



>> 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.
>
> We're [current hat: Cambridge] interested in CHERI as an enforcement
> mechanism for SFI-like things (though in the kernel you need to be very
> careful about MMU access), though this probably wouldn't be a good GSoC
> project[1].  Having something that works on commodity hardware would be
> interesting.  FreeBSD has also been accepted as a GSoC organisation, so a
> project along these lines would be more appropriate there - John, you're
> welcome to sign up as a FreeBSD mentor if that would make more sense and
> you're interested in mentoring KCoFi-related projects.
>
> David
>
> [1] It's not very interesting to people who aren't running CHERI CPUs, but
> it might be possible to arrange an internship at Cambridge if there's an
> interested student.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150318/3f6daa93/attachment.html>