<div dir="ltr">can anyone please review my proposal. I need suggestions on timeline on the PNaCL improvements and also its improvements.<br><br><div><div><div><strong>Project Goals:</strong> <br>The primary objective
of this project is to implement stronger SFI mechanism in existing
kernel of KCoFI.The following are three broad improvements I aim to
implement in KCoFI: <br> 1 .Implement a stronger call graph using libLTO tool. <br> 2.To replace KCoFI's SFI instrumehntation with that found in Portable Native Client (PNaCL).</div><div> </div><div>CFI
is a compiler based security mechanism that protects against the
malicious programs that hijack the flow of control of the program<strong>[1]</strong>. KCoFI <strong>[2]</strong>
is a security mechanism for operating system kernel that extends the
CFI technique to os kernel. Thus KCoFI is a security mechanism that
protects commodity operating systems from classical control- flow hijack
attacks, return-to-user attacks, and code segment modification attacks.
<br>KCoFI uses traditional label-based protection for programmed indirect jumps <strong>[1] </strong>but
adds a thin run-time layer linked into the OS that protects some key OS
data structures like thread stacks and monitors all low-level state
manipulations performed by the OS.</div><div>KCoFI is an LLVM based
kernel. In this project I aim to undertake the improvements in the KCoFI
mechanism to make it stronger against ever growing future attacks.</div><div>Software Fault Isolation(SFI) is the act of separating distrusted extensions that are possibly faulty.</div><div> </div><div>This
project is organized as a two part project in which the first part aims
to implement a stronger call graph and the second part integrates the
SFI Instrumentation found in PNaCl(Portable Native Client) to KCoFI and
replace the older SFI Instrumentations.</div><div> </div></div><div><strong>Portable Native Client</strong>
extends that technology of sandboxing used by Native CLlent with
architecture independence, letting developers compile their code once to
run in any website and on any architecture with ahead-of-time (AOT)
translation.</div><div>This project will make use of Software Fault
Isolation(SFI) Instrumentations of PNaCL and integrate them with KCoFI
while replacing the older SFI Instrumentations of KCoFI.</div><div> </div><div>The following is the things to do in the project:<br><strong>1. Implementing a stronger call graph:</strong>
in this part of the project the FreeBSD kernel will be compiled using
the libTO tool. This will involve writing patches that build to IR, use
llvm-link to run LTO and then link the resulting binary. This project
will involve delving further into the llvm bundle. It will requires
modifying the CFI MachineFunctionPass to support multiple labels.<span class="im"><br></span></div><div>Since, <span class="im">KCoFI currently uses a really weak call-graph (all functions and call sites are equivalence-classed), thus a</span>fter compiling the FreeBSD kernel with libLTO, <span class="im">first
task to do is to improve the CFI instrumentation to enforce a more
accurate call graph. This implementation will be done by using libLTO to
compute a whole-kernel call graph and then using different CFI labels
for different nodes in the call graph.<br></span><span class="im"> It
could be improved by using libLTO to compute a whole-kernel call graph
and then using different CFI labels for different nodes in the call
graph.<br> <br> A second improvement would be to remove CFI labels that
are unnecessary. Any function that is only called directly does not
need a CFI label. Again, to make this optimization work, a whole-kernel
analysis will be done via libLTO.<br> </span></div><div> </div><div><span class="im">Another improvement to undertake is to implement Forward Edge Call graph<strong>[5]</strong>.</span></div><div> </div></div><div> </div><div><strong>2.Replace KCoFI's SFI instrumentation with the Instrumentation found in Portable Native Client (PNaCL): </strong></div><div>The
PNaCL implementation should be much better than KCoFI's. PNacl and NaCL
both are open source.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,
which is the work that I will undertake as a part of the project.</div><div> </div><div>This
project will require modifying the CFI MachineFunctionPass and using
either the LLVM CallGraphAnalysis pass or the DSA CallGraph pass. It
will also require modification of the low-level KCoFI run-time library
(i.e., the implementation of the SVA-OS instructions, as some of them
need to do CFI checks).<span class="im"><br></span><br><strong>Timeline and Roadmap:</strong></div><div>Since
it is a big project and I will be using the existing code of KCoFI I
will be going ahead with the Iterative Enhancement model of Software
Development Process</div><div><strong>Week 1:</strong>Discussion with my mentor on documentation style and the code.</div><div><strong>Week 2 to Week 3:</strong> Writing the patches that build to IR and use llvm- link to run LTO with FreeBSD</div><div><strong>Week 4 to Week 6:</strong> Compiling the kernel with libLTO tool. In this week I will write the methods to build a strong call graph.</div><div><strong>Week 7:</strong> Testing the call graphs with proper benchmarking.</div><div><strong>Week 8 to Week 9:</strong> using the PNaCl and NaCL SFI techniques and implementing them in the kernel.</div><div><strong>Week 10:</strong> using the NaCl to support multiple sandboxing in same address space for for multiple processes in an os kernel.</div><div><strong>Week 11:</strong>
testing the new sandboxing techniques together with the previous
techniques of stronger call graph imlemntation with proper benchmarking
of the compile time.</div><div><strong>WEEK 12:</strong> Evaluating the performance of the improvements.</div><div> </div><div><strong>Criteria of Success:</strong></div><div>1. Newer stronger call graph implementation. Evaluation done using proper benchmarking.</div><div>2.Implmentation of SFI Instrumentation of PNaCl,</div><div> </div><div>Thus
by the end of the summer improving the call graph, replacing the SFI
instrumentation, and evaluating the performance will be the work that I
will complete.<span class="im"><br></span></div><div> </div><div><strong>Brief Bio:</strong></div><div>I
am a third year undergraduate in Computer Science and Engineering. My
interests lie in Computer Architecture and Operating System. I like
working with the machinistic aspects of computer science. My rigorous
programming experience has spanned across fields such as Database
Management System, Operating Systems, Networking , Artificial
Intelligence and Machine Learning. I see myself as a hardworking and
sincere, at the same time passionate about building newer software. I
also have experience programing the Microprocessor 8085 and 8086.</div><div>I am proficient in C and C++.</div><div> </div><div> </div><div><strong>References:</strong></div><div>[1] M.
Abadi, M. Budiu, U. Erlingsson, and J. Ligatti, “Control-flow integrity
principles, implementations, and applications,” ACM Trans. Inf. Syst.
Secur. , vol. 13, pp. 4:1–4:40, November 2009.</div><div>[2] KCoFI: Complete Control-Flow Integrity for Commodity Operating System Kernels</div><div>[3]
M. Zhang and R. Sekar, “Control flow integrity for COTS binaries,” in
Proceedings of the 22nd USENIX conference on Security , ser. SEC’13. <br>Berkeley, CA, USA: USENIX Association, 2013, pp. 337–352. <br>[4]
J. Criswell, A. Lenharth, D. Dhurjati, and V. Adve, “Secure Virtual
Architecture: A Safe Execution Environment for Commodity Operating
Systems,” in Proc. ACM SIGOPS Symp. on Op. Sys. Principles</div>[5]
<div>
<a href="http://dl.acm.org/citation.cfm?id=2671285&CFID=492903293&CFTOKEN=22797912">
Caroline Tice , Tom Roeder , Peter Collingbourne , Stephen
Checkoway , Úlfar Erlingsson , Luis Lozano , Geoff Pike, Enforcing
forward-edge control-flow integrity in GCC & LLVM, Proceedings of
the 23rd USENIX conference on Security Symposium, p.941-955, August
20-22, 2014, San Diego, CA</a><br><br><br><br><br></div><div>Can anyone also review it on my dashboard???<br>
</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Regards<div>Aditya Verma</div><div>Junior Undergraduate</div><div>IDD Computer Sc & Engg</div><div>IIT(BHU), Varanasi(UP)</div></div></div></div>
<br><div class="gmail_quote">On Fri, Mar 27, 2015 at 5:45 AM, John Criswell <span dir="ltr"><<a href="mailto:jtcriswel@gmail.com" target="_blank">jtcriswel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<div>On 3/26/15 5:56 PM, Aditya Verma IDD M
Tech Computer Sc & Engg., IIT(BHU), Varanasi (U.P.) wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>Hi <br>
</div>
In my previous mail I mentioned the project on KCoFI(
the control FLow integrity methods for commodity
hardware <a href="http://sva.cs.illinois.edu/pubs/KCoFI-Oakland-2014.pdf" target="_blank">http://sva.cs.illinois.edu/pubs/KCoFI-Oakland-2014.pdf</a>
).<br>
</div>
<div>Will it be more helpful to the community if I do the
improvements number #1 and #3 mentioned in my previous
mail to the mailing list or if i try to port it to arm
architecture?<br>
</div>
<div>I have decided to go ahead with the improvements #1
and #3 that are improving the call graph and porting the
KCoFI SFI methods to the ones used in NaCl and PNaCl. It
seems to me the community is more interested towards the
SFI methods.<br>
</div>
<div>If the course of the project permits I may also
contribute to the fourth improvement that you mentioned.<br>
</div>
<div><br>
</div>
Earlier I mentioned three modifications to improve the
KCoFI project. <br>
</div>
After the valuable feedback from the members I am deciding
to go ahead with<br>
1. Implementing a stronger call graph: in this part of the
project the FreeBSD kernel will be compiled using the libTO
tool. This will involve writing some patches that build to
IR, use llvm-link to run LTO and then link the resulting
binary. This project will involve delving further into the
llvm bundle.<br>
</div>
2. PNacl and NaCL both are open source.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, which is the
work that I will undertake as a part of the project. I will be
trying to integrate the Forward Edge Call Graph techniques
also in this project. <br>
</div>
<div>3. porting the newer version of FreeBSD kernel to SVA-OS
instruction set.<br>
</div>
<div><br>
As a brief timeplane<br>
</div>
<div>Since it is a big project and I will be using the existing
code of KCoFI I will be going ahead with the Iterative
Enhancement model of Software Development Process<br>
</div>
<div>Week 1:Discussion with my mentor on documentation style and
the code.<br>
</div>
<div>Week 2 to Week 3: Writing the patches that build to IR and
use llvm- link to run LTO with FreeBSD<br>
</div>
<div>Week 4: Compiling the kernel with libLTO tool. In this week
I will write the methods to build a strong call graph.<br>
</div>
</div>
</blockquote>
<br></span>
You will either use libLTO or you will use opt/llvm-link to do
whole-program analysis on the kernel. As such, you will do one or
the other but not both. My preference would be to try a version of
libLTO with all optimizations disabled first and then fall back to
using opt/llvm-link/llc if that fails.<br>
<br>
I also think that extending the current KCoFI CFI implementation
with stronger call graph support will take more than a week. It
requires modifying the CFI MachineFunctionPass to support multiple
labels.<span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>Week 5: Testing the call graphs.<br>
</div>
<div>Week 6-7: using the PNaCl and NaCL SFI techniques and
implementing them in the kernel.<br>
</div>
<div>Week 8: using the NaCl to support multiple sandboxing in
same address space for for multiple processes in an os kernel.<br>
</div>
</div>
</blockquote>
<br></span>
KCoFI only needs to support a single "sandbox," so to speak. The
KCoFI run-time library has data structures which the kernel must not
overwrite. There are no other per-process "sandboxes" that KCoFI
needs to implement.<br>
<br>
I'm also thinking that, for x86, KCoFI should replace the SFI
instrumentation with the WP-bit mechanism that it uses to protect
page table pages. This should be far more efficient than SFI
instrumentation.<span class=""><br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>Week 9: testing the new sandboxing techniques together with
the previous techniques of stronger call graph imlemntation
with proper benchmarking of the compile time.<br>
</div>
</div>
</blockquote>
<br></span>
I don't think the current KCoFI implementation is robust enough to
compile an entire FreeBSD kernel (otherwise, I would have run it as
a benchmark for the paper). You should evaluate the performance
using microbenchmarks and the networking benchmarks used in the
KCoFI paper (which should still work after you've made your
changes).<span class=""><br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>Week 10-11: Porting the newer version of the FReeBSD kernel
to SVA-OS instruction set.<br>
</div>
</div>
</blockquote>
<br></span>
I wouldn't add this to the timeline. If you're making significant
changes to the implementation, then I'd stick with the current
FreeBSD 9.0 implementation <br><span class="">
<br>
<blockquote type="cite">
<div dir="ltr">
<div>WEEK 12: testing of the complete project with real world
malicious programs.<br>
</div>
</div>
</blockquote>
<br></span>
I would not evaluate the prototype this way. Testing exploits is
time consuming and non-conclusive. I think testing the security
efficacy of the prototype is beyond the scope of GSoC; I'll be
having a student of my own begin work on new methods of evaluating
defenses against code-reuse attacks. I suspect that, by the end of
the summer, merely improving the call graph, replacing the SFI
instrumentation, and evaluating the performance will be enough work.<span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>What exactly should i do in the porting to the SFI
techniques of PNacl and Nacl. Will it sandbox each process
using its call graph or will it sandbox some unprivileged
processes making the use of capabilities?<br>
</div>
</div>
</blockquote>
<br></span>
If you've read and understood the KCoFI paper, then you should know
the answer to this question.<span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>How much will the project involve writing into the llvm
code bundle? <br>
</div>
</div>
</blockquote>
<br></span>
The project will require modifying the CFI MachineFunctionPass and
using either the LLVM CallGraphAnalysis pass or the DSA CallGraph
pass. It will also require modification of the low-level KCoFI
run-time library (i.e., the implementation of the SVA-OS
instructions, as some of them need to do CFI checks).<span class=""><br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>Should I apply in llvm or in FreeBSD? If I apply in FreeBSD
then I believe the project of porting the kernel to arm
architecture will be of more use there. Or should I submit
proposals to both the organizations?<br>
</div>
</div>
</blockquote>
<br></span>
That's a good question, but I'm afraid I don't have a good answer.
My impression (based on very limited data) is that the FreeBSD
community is a bit more open to this project than the LLVM
community.<span class=""><br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>I just want to ask how should I try to convince other
mentors that this project will be useful for the llvm
community as a whole?<br>
<br>
</div>
<div>The things that I am not able to write in my proposal are
how to give strong reasons to convince the mentors that this
project will be useful for the llvm community as a whole. Also
I need some more suggestions about the timeline and the
roadmap if you can help.<br>
</div>
</div>
</blockquote>
<br></span>
I think the benefit to the LLVM community is that we'll have an
operating system kernel that is better hardened against control-flow
hijack attacks, and it's implementation will rely upon LLVM.<span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
Sorry for being late I was busy with my mid semester
examinations. <br>
And unfortunately while installing FreeBSD on my system
something went wrong with the EFI file system and my entire HDD
and windows was lost.<br>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div dir="ltr">I will be uploading the
proposal soon.<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br></span>
Please include a CV or resume in your proposal. One of the things a
strong proposal will do (both with a CV/resume and with text within
the proposal) is argue that you're the right person for the job.<br>
<br>
Regards,<br>
<br>
John Criswell<br>
<br>
<blockquote type="cite"><span class="">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div dir="ltr"><br>
<br>
Regards
<div>Aditya Verma</div>
<div>Junior Undergraduate</div>
<div>IDD Computer Sc & Engg</div>
<div>IIT(BHU), Varanasi(UP)</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</span><pre>_______________________________________________
LLVM Developers mailing list
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><span class="HOEnZb"><font color="#888888">
</font></span></pre><span class="HOEnZb"><font color="#888888">
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
<br>
<pre cols="72">--
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
<a href="http://www.cs.rochester.edu/u/criswell" target="_blank">http://www.cs.rochester.edu/u/criswell</a></pre>
</font></span></div>
</blockquote></div><br></div>