llvm dev - Mar 2015 - [LLVMdev] GSOC project on KCoFI

Hi
In my previous mail I mentioned the project on KCoFI( the control FLow
integrity methods for commodity hardware
http://sva.cs.illinois.edu/pubs/KCoFI-Oakland-2014.pdf ).
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?
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.
If the course of the project permits I may also contribute to the fourth
improvement that you mentioned.

Earlier I mentioned three modifications to improve the KCoFI project.
After the valuable feedback from the members I am deciding to go ahead with
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.
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.
3. porting the newer version of FreeBSD kernel to SVA-OS instruction set.

As a brief timeplane
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
Week 1:Discussion with my mentor on documentation style and the code.
Week 2 to Week 3: Writing the patches that build to IR and use llvm- link
to run LTO with FreeBSD
Week 4: Compiling the kernel with libLTO tool. In this week I will write
the methods to build a strong call graph.
Week 5: Testing the call graphs.
Week 6-7: using the PNaCl and NaCL SFI techniques and implementing them in
the kernel.
Week 8: using the NaCl to support multiple sandboxing in same address space
for for multiple processes in an os kernel.
Week 9: testing the new sandboxing techniques together with the previous
techniques of stronger call graph imlemntation with proper benchmarking of
the compile time.
Week 10-11: Porting the newer version of the FReeBSD kernel to SVA-OS
instruction set.
WEEK 12: testing of the complete project with real world malicious programs.

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?

How much will the project involve writing into the llvm code bundle?
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?
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?

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.

Sorry for being late I was busy with my mid semester examinations.
And unfortunately while installing FreeBSD on my system something went
wrong with the EFI file system and my entire HDD and windows was lost.
I will be uploading the proposal soon.


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/20150326/05cfc063/attachment.html>

On 3/26/15 5:56 PM, Aditya Verma IDD M Tech Computer Sc & Engg., 
IIT(BHU), Varanasi (U.P.) wrote:
> Hi
> In my previous mail I mentioned the project on KCoFI( the control FLow 
> integrity methods for commodity hardware 
> http://sva.cs.illinois.edu/pubs/KCoFI-Oakland-2014.pdf ).
> 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?
> 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.
> If the course of the project permits I may also contribute to the 
> fourth improvement that you mentioned.
>
> Earlier I mentioned three modifications to improve the KCoFI project.
> After the valuable feedback from the members I am deciding to go ahead 
> with
> 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.
> 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.
> 3. porting the newer version of FreeBSD kernel to SVA-OS instruction set.
>
> As a brief timeplane
> 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
> Week 1:Discussion with my mentor on documentation style and the code.
> Week 2 to Week 3: Writing the patches that build to IR and use llvm- 
> link to run LTO with FreeBSD
> Week 4: Compiling the kernel with libLTO tool. In this week I will 
> write the methods to build a strong call graph.
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.

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.
> Week 5: Testing the call graphs.
> Week 6-7: using the PNaCl and NaCL SFI techniques and implementing 
> them in the kernel.
> Week 8: using the NaCl to support multiple sandboxing in same address 
> space for for multiple processes in an os kernel.
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.

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.

> Week 9: testing the new sandboxing techniques together with the 
> previous techniques of stronger call graph imlemntation with proper 
> benchmarking of the compile time.
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).

> Week 10-11: Porting the newer version of the FReeBSD kernel to SVA-OS 
> instruction set.
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
> WEEK 12: testing of the complete project with real world malicious 
> programs.
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.
>
> 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?
If you've read and understood the KCoFI paper, then you should know the 
answer to this question.
>
> How much will the project involve writing into the llvm code bundle?
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).

> 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?
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.

> 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?
>
> 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.
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.
>
> Sorry for being late I was busy with my mid semester examinations.
> And unfortunately while installing FreeBSD on my system something went 
> wrong with the EFI file system and my entire HDD and windows was lost.
> I will be uploading the proposal soon.
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.

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/20150326/f52958b4/attachment.html>

can anyone please review my proposal. I need suggestions on timeline on the
PNaCL improvements and also its improvements.

*Project Goals:*
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:
      1 .Implement a stronger call graph using libLTO tool.
      2.To replace KCoFI's SFI instrumehntation with that found in Portable
Native Client (PNaCL).

CFI is a compiler based security mechanism that protects against the
malicious programs that hijack the flow of control of the program*[1]*.
KCoFI *[2]* 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.
KCoFI uses traditional label-based protection for programmed indirect jumps
*[1] *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.
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.
Software Fault Isolation(SFI) is the act of separating distrusted
extensions that are possibly faulty.

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.

*Portable Native Client* 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.
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.

The following is the things to do in the project:
*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 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.
Since, KCoFI currently uses a really weak call-graph (all functions and
call sites are equivalence-classed), thus after compiling the FreeBSD
kernel with libLTO, 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.
 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.

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.

Another improvement to undertake is to implement Forward Edge Call graph
*[5]*.


*2.Replace KCoFI's SFI instrumentation with the Instrumentation  found in
Portable Native Client (PNaCL): *
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.

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).

*Timeline and Roadmap:*
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
*Week 1:*Discussion with my mentor on documentation style and the code.
*Week 2 to Week 3:* Writing the patches that build to IR and use llvm- link
to run LTO with FreeBSD
*Week 4 to Week 6:* Compiling the kernel with libLTO tool. In this week I
will write the methods to build a strong call graph.
*Week 7:* Testing the call graphs with proper benchmarking.
*Week 8 to Week 9:* using the PNaCl and NaCL SFI techniques and
implementing them in the kernel.
*Week 10:* using the NaCl to support multiple sandboxing in same address
space for for multiple processes in an os kernel.
*Week 11:* testing the new sandboxing techniques together with the previous
techniques of stronger call graph imlemntation with proper benchmarking of
the compile time.
*WEEK 12:* Evaluating the performance of the improvements.

*Criteria of Success:*
1. Newer stronger call graph implementation. Evaluation done using proper
benchmarking.
2.Implmentation of SFI Instrumentation of PNaCl,

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.

*Brief Bio:*
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.
I am proficient in C and C++.


*References:*
[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.
[2] KCoFI: Complete Control-Flow Integrity for Commodity Operating System
Kernels
[3] M. Zhang and R. Sekar, “Control flow integrity for COTS binaries,” in
Proceedings of the 22nd USENIX conference on Security , ser. SEC’13.
Berkeley, CA, USA: USENIX Association, 2013, pp. 337–352.
[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
[5]
 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
<http://dl.acm.org/citation.cfm?id=2671285&CFID=492903293&CFTOKEN=22797912>




Can anyone also review it on my dashboard???

Regards
Aditya Verma
Junior Undergraduate
IDD Computer Sc & Engg
IIT(BHU), Varanasi(UP)

On Fri, Mar 27, 2015 at 5:45 AM, John Criswell <jtcriswel at gmail.com>
wrote:
>  On 3/26/15 5:56 PM, Aditya Verma IDD M Tech Computer Sc & Engg.,
> IIT(BHU), Varanasi (U.P.) wrote:
>
>    Hi
>  In my previous mail I mentioned the project on KCoFI( the control FLow
> integrity methods for commodity hardware
> http://sva.cs.illinois.edu/pubs/KCoFI-Oakland-2014.pdf ).
>  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?
>  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.
>  If the course of the project permits I may also contribute to the fourth
> improvement that you mentioned.
>
>  Earlier I mentioned three modifications to improve the KCoFI project.
>  After the valuable feedback from the members I am deciding to go ahead
> with
> 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.
>  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.
>  3. porting the newer version of FreeBSD kernel to SVA-OS instruction set.
>
> As a brief timeplane
>  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
>  Week 1:Discussion with my mentor on documentation style and the code.
>  Week 2 to Week 3: Writing the patches that build to IR and use llvm-
> link to run LTO with FreeBSD
>  Week 4: Compiling the kernel with libLTO tool. In this week I will write
> the methods to build a strong call graph.
>
>
> 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.
>
> 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.
>
>  Week 5: Testing the call graphs.
>  Week 6-7: using the PNaCl and NaCL SFI techniques and implementing them
> in the kernel.
>  Week 8: using the NaCl to support multiple sandboxing in same address
> space for for multiple processes in an os kernel.
>
>
> 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.
>
> 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.
>
>
>  Week 9: testing the new sandboxing techniques together with the previous
> techniques of stronger call graph imlemntation with proper benchmarking of
> the compile time.
>
>
> 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).
>
>
>  Week 10-11: Porting the newer version of the FReeBSD kernel to SVA-OS
> instruction set.
>
>
> 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
>
>  WEEK 12: testing of the complete project with real world malicious
> programs.
>
>
> 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.
>
>
>  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?
>
>
> If you've read and understood the KCoFI paper, then you should know the
> answer to this question.
>
>
>  How much will the project involve writing into the llvm code bundle?
>
>
> 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).
>
>
>  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?
>
>
> 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.
>
>
>  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?
>
>  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.
>
>
> 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.
>
>
>  Sorry for being late I was busy with my mid semester examinations.
> And unfortunately while installing FreeBSD on my system something went
> wrong with the EFI file system and my entire HDD and windows was lost.
>       I will be uploading the proposal soon.
>
>
> 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.
>
> Regards,
>
> John Criswell
>
>
>
> Regards
> Aditya Verma
> Junior Undergraduate
> IDD Computer Sc & Engg
> IIT(BHU), Varanasi(UP)
>
>
> _______________________________________________
> LLVM Developers mailing listLLVMdev at cs.uiuc.edu        
http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> --
> John Criswell
> Assistant Professor
> Department of Computer Science, University of
Rochesterhttp://www.cs.rochester.edu/u/criswell
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150327/661a62b3/attachment.html>