<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 17, 2015 at 1:39 AM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 17 Mar 2015, at 09:43, John Criswell <<a href="mailto:jtcriswel@gmail.com">jtcriswel@gmail.com</a>> wrote:<br>
><br>
> On 3/16/15 11:51 PM, Aditya Verma IDD M Tech Computer Sc & Engg., IIT(BHU), Varanasi (U.P.) wrote:<br>
>> Hi<br>
>><br>
>> 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:<br>
><br>
> You might want to include a link to the KCoFI paper for those who do not know what KCoFI is.<br>
><br>
>><br>
>> 1. To improve the call graph used in KCoFI. Implement a stronger call graph.<br>
>> 2. Port the KCoFI to another architecture such as ARM or x86-32.<br>
>> 3 .To replace KCoFI's SFI instrumentation with that found in Portable Native Client (PNaCL)<br>
><br>
> 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.<br>
><br>
> 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).<br>
<br>
</span>ARMv8 is probably the most interesting other target, though it's currently quite immature in FreeBSD.  Andy Turner is working on the port.<br>
<span class=""><br>
> 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.<br>
<br>
</span>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.<br>
<br>
[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).<br>
<span class=""><br>
> 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.<br>
><br>
> 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. :)<br>
<br>
</span>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.<br></blockquote><div><br></div><div>PNaCl is open source and can be checked-out and build with the following instructions:</div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div><a href="https://sites.google.com/a/chromium.org/dev/nativeclient/pnacl/developing-pnacl">https://sites.google.com/a/chromium.org/dev/nativeclient/pnacl/developing-pnacl</a></div></div></div></blockquote><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>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".</div><div><br></div><div>I recommend looking at:</div><div> - The work Tom Roeder recently did in LLVM (it was recently deeleted from the code base).</div><div> - The work David Brazdil did in PNaCl called MinSFI to do compiler-based sandboxing.</div><div> - Peter Collingbourne's current sandboxing work in LLVM.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">>> 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.<br>
><br>
> 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.<br>
<br>
</span>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.<br>
<br>
David<br>
<br>
[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.<br>
<div class=""><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div></div>