<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 3/26/15 5:56 PM, Aditya Verma IDD M
Tech Computer Sc & Engg., IIT(BHU), Varanasi (U.P.) wrote:<br>
</div>
<blockquote
cite="mid:CA+59L6gdWRkhXCeC0srLZzA8y5-qxa79A-HH58QxFe-ud7Ajvw@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
<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 moz-do-not-send="true"
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>
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.<br>
<br>
<blockquote
cite="mid:CA+59L6gdWRkhXCeC0srLZzA8y5-qxa79A-HH58QxFe-ud7Ajvw@mail.gmail.com"
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>
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.<br>
<br>
<br>
<blockquote
cite="mid:CA+59L6gdWRkhXCeC0srLZzA8y5-qxa79A-HH58QxFe-ud7Ajvw@mail.gmail.com"
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>
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).<br>
<br>
<br>
<blockquote
cite="mid:CA+59L6gdWRkhXCeC0srLZzA8y5-qxa79A-HH58QxFe-ud7Ajvw@mail.gmail.com"
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>
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>
<br>
<blockquote
cite="mid:CA+59L6gdWRkhXCeC0srLZzA8y5-qxa79A-HH58QxFe-ud7Ajvw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>WEEK 12: testing of the complete project with real world
malicious programs.<br>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:CA+59L6gdWRkhXCeC0srLZzA8y5-qxa79A-HH58QxFe-ud7Ajvw@mail.gmail.com"
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>
If you've read and understood the KCoFI paper, then you should know
the answer to this question.<br>
<br>
<blockquote
cite="mid:CA+59L6gdWRkhXCeC0srLZzA8y5-qxa79A-HH58QxFe-ud7Ajvw@mail.gmail.com"
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>
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).<br>
<br>
<br>
<blockquote
cite="mid:CA+59L6gdWRkhXCeC0srLZzA8y5-qxa79A-HH58QxFe-ud7Ajvw@mail.gmail.com"
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>
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.<br>
<br>
<br>
<blockquote
cite="mid:CA+59L6gdWRkhXCeC0srLZzA8y5-qxa79A-HH58QxFe-ud7Ajvw@mail.gmail.com"
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>
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.<br>
<br>
<blockquote
cite="mid:CA+59L6gdWRkhXCeC0srLZzA8y5-qxa79A-HH58QxFe-ud7Ajvw@mail.gmail.com"
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>
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
cite="mid:CA+59L6gdWRkhXCeC0srLZzA8y5-qxa79A-HH58QxFe-ud7Ajvw@mail.gmail.com"
type="cite">
<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 class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a class="moz-txt-link-freetext" href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
</blockquote>
<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>