Aditya Verma IDD M Tech Computer Sc & Engg., IIT(BHU), Varanasi (U.P.)
2015-Mar-16 21:51 UTC
[LLVMdev] GSOC:Control Flow integrity for kernal
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: 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) 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. Regards Aditya Verma Junior Undergraduate IDD Computer Sc & Engg IIT(BHU), Varanasi(UP) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150317/2477afd1/attachment.html>
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>
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.>> 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.