<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 3/27/15 7:34 AM, Aditya Verma IDD M
Tech Computer Sc & Engg., IIT(BHU), Varanasi (U.P.) wrote:<br>
</div>
<blockquote
cite="mid:CA+59L6jaxHO=xErCLma7SeZ=L=Emd6HsTcOsC7vcw+wd8Swc-A@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
<div dir="ltr">can anyone please review my proposal. I need
suggestions on timeline on the PNaCL improvements and also its
improvements.<br>
</div>
</blockquote>
<br>
Just a nitpick: I prefer proposals to be in PDF format. I find
typeset text easier to read.<br>
<br>
<blockquote
cite="mid:CA+59L6jaxHO=xErCLma7SeZ=L=Emd6HsTcOsC7vcw+wd8Swc-A@mail.gmail.com"
type="cite">
<div dir="ltr"><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>
</blockquote>
<br>
As I stated in my last email, I've changed my mind about replacing
the SFI implementation in KCoFI with the PNaCL implementation. It
makes more sense to protect the SVA-OS internal data structures
using the WP-bit trick that it uses to protect the page table
pages. This should alleviate the need for SFI and make the
implementation faster.<br>
<br>
<blockquote
cite="mid:CA+59L6jaxHO=xErCLma7SeZ=L=Emd6HsTcOsC7vcw+wd8Swc-A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<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>
</blockquote>
<br>
Again, I think it's best to remove SFI and replace it with a more
efficient mechanism.<br>
<br>
<blockquote
cite="mid:CA+59L6jaxHO=xErCLma7SeZ=L=Emd6HsTcOsC7vcw+wd8Swc-A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<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>
</blockquote>
<br>
KCoFI already implements checks on indirect function calls (i.e.,
forward edges in the call graph).<br>
<br>
<blockquote
cite="mid:CA+59L6jaxHO=xErCLma7SeZ=L=Emd6HsTcOsC7vcw+wd8Swc-A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div> </div>
</div>
<div> </div>
<div><strong>2.Replace KCoFI's SFI instrumentation with the
Instrumentation found in Portable Native Client (PNaCL): <br>
</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></div>
</div>
</blockquote>
<br>
To be clear, KCoFI does not need to sandbox applications. It only
needs to sandbox the kernel from the SVA-OS run-time library (also
called the KCoFI run-time library in the KCoFI paper). There is no
per-application sandbox in KCoFI.<br>
<br>
<br>
<blockquote
cite="mid:CA+59L6jaxHO=xErCLma7SeZ=L=Emd6HsTcOsC7vcw+wd8Swc-A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><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>
</blockquote>
<br>
This step will not take a week. If selected, we'll have an initial
meeting and have you begin work within the first week.<br>
<br>
<blockquote
cite="mid:CA+59L6jaxHO=xErCLma7SeZ=L=Emd6HsTcOsC7vcw+wd8Swc-A@mail.gmail.com"
type="cite">
<div dir="ltr">
<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>
</blockquote>
<br>
You should restate this to say that you'll modify the CFI
instrumentation pass in weeks 4, 5, and 6. I would allot 3 weeks to
improving the call graph.<br>
<br>
<blockquote
cite="mid:CA+59L6jaxHO=xErCLma7SeZ=L=Emd6HsTcOsC7vcw+wd8Swc-A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><strong>Week 7:</strong> Testing the call graphs with
proper benchmarking.</div>
</div>
</blockquote>
<br>
What does "testing the call graphs with proper benchmarking" mean?<br>
<br>
<blockquote
cite="mid:CA+59L6jaxHO=xErCLma7SeZ=L=Emd6HsTcOsC7vcw+wd8Swc-A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><strong>Week 8 to Week 9:</strong> using the PNaCl and NaCL
SFI techniques and implementing them in the kernel.</div>
</div>
</blockquote>
<br>
You should take 2-3 weeks to modify KCoFI to alleviate the current
SFI pass. Take out Week 7 to make room if necessary since this will
be a significant job.<br>
<br>
<blockquote
cite="mid:CA+59L6jaxHO=xErCLma7SeZ=L=Emd6HsTcOsC7vcw+wd8Swc-A@mail.gmail.com"
type="cite">
<div dir="ltr">
<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>
</blockquote>
<br>
Again, you only need one sandbox. KCoFI uses sandboxing to keep the
kernel from accessing SVA-OS internal data structures. Also, you
should not use SFI; you should use the the WP-bit trick that KCoFI
uses to protect page table pages.<br>
<br>
<br>
<blockquote
cite="mid:CA+59L6jaxHO=xErCLma7SeZ=L=Emd6HsTcOsC7vcw+wd8Swc-A@mail.gmail.com"
type="cite">
<div dir="ltr">
<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>
</blockquote>
<br>
My experience suggests that performance evaluation will take two
weeks.<br>
<br>
<blockquote
cite="mid:CA+59L6jaxHO=xErCLma7SeZ=L=Emd6HsTcOsC7vcw+wd8Swc-A@mail.gmail.com"
type="cite">
<div dir="ltr">
<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>
</blockquote>
<br>
You should provide information on previous projects that you've
completed successfully. This will make your claims about your
experience far more concrete.<br>
<br>
Regards,<br>
<br>
John Criswell<br>
<br>
<pre class="moz-signature" cols="72">--
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
<a class="moz-txt-link-freetext" href="http://www.cs.rochester.edu/u/criswell">http://www.cs.rochester.edu/u/criswell</a></pre>
</body>
</html>