<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><br></span></div><div>Since, <span>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>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> 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>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><br></span><br><strong>Timeline and Roadmap:</strong></div><span class="im"><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></span><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><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]
<a href="http://dl.acm.org/citation.cfm?id=2671285&CFID=492903293&CFTOKEN=22797912" target="_blank">
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><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>
</div>