Performance Aware Secure Code Partitioning

1. Performance Aware Secure Code Partitioning Sri Hari Krishna Narayanan, Mahmut Kandemir, Richard Brooks Presenter : Sri Hari Krishna Narayanan

2. Outline • Introduction to secure code partitioning • Motivation through multi level security • Our Code Partitioning Domain • Workload Balancing Algorithm • Example • Results

3. Original Application and data Compiler thread thread thread thread thread H0 H1 H2 H3 H4 Introduction • Secure code partitioning is a process that partitions code and data among several mutually untrusted hosts that need to co-operate to complete a task in parallel. Authenticated trust declarations

4. Classic MLS lattice of 4 levels unclassified < confidential < secret < top secret Motivation – Multi level security • Why performance aware? - Secure code partitioning when performed in a performance agnostic manner can lead to skewed load across the hosts. • Let us look at Multi-Level-Security (MLS) • Uses qualifiers on data to classify them according to their sensitivity level. • Uses qualifiers on hosts to classify them according to their capability level. Categories – Used to separate data COMINT, HUMINT, ELINT Data A : (CONFIDENTIAL) Data B : (SECRET) Data C : (UNCLASSIFIED) Data A : (CONFIDENTIAL, {ELINT}) Data B : (SECRET, {COMINT}) Data C : (UNCLASSIFIED , {HUMINT})

5. COMINT HUMINT ELINT TOP SECRET SECRET Data A Data B Data C CONFIDENTIAL UNCLASSIFIED Multilevel Security Data A : (CONFIDENTIAL, {ELINT}) Data B : (SECRET, {COMINT}) Data C : (UNCLASSIFIED , {HUMINT}) Host A : (CONFIDENTIAL, {COMINT, HUMINT}) Host B : (CONFIDENTIAL, {ELINT}) Host C : (TOP SECRET, {COMINT, HUMINT, ELINT})

6. COMINT HUMINT ELINT TOP SECRET SECRET Data A Data B Data C CONFIDENTIAL Host C Host B Host C UNCLASSIFIED Host A Host C Multilevel Security Data A : (CONFIDENTIAL, {ELINT}) Data B : (SECRET, {COMINT}) Data C : (UNCLASSIFIED , {HUMINT}) Host A : (CONFIDENTIAL, {COMINT, HUMINT}) Host B : (CONFIDENTIAL, {ELINT}) Host C : (TOP SECRET, {COMINT, HUMINT, ELINT})

7. H2 H0 H3 H2 H0 H1 H4 H1 H4 H3 Our Code Partitioning Domain • The aim is to partition a given task evenly among a set of hosts. • However, different hosts have access to different portions of the data. • Further, hosts are hierarchically related. E.g. Host 1 can access all the data that Host 4 and Host 3 can. Data Decompositions Host Hierarchy Tree

8. Original Application and Data H2 H0 H3 Compiler H2 H0 H1 H4 H1 H4 H4 thread thread thread thread thread H0 H1 H2 H3 H4 Our Code Partitioning Domain

9. Workload Balancing Challenges • There are three challenges • Representing the data and computation that can be performed on them • In this work, we target codes that are structured as a series of loops that access data. • So the unit of workload distribution is a loop iteration. • Calculating the initial/default workload on each host • Reassigning the workload of the hosts • Three algorithms

10. Determining the data and the iterations Data accessed by a host in an iteration All iterations that access a particular data object on a host that may be accessed by a host All the iterations that may be executed on a host Default iterations that are executed on a host

11. Reassigning the workload ReassignHHT() 1: Navg := Totalnumberofiterations / Totalnumberofhosts 2: BottomToTop(hroot,Navg) 3: while carryout(hroot, Ik) > 0 do 4: Navg := Navg + Navg * 0.1 5: TopToBottom(hroot,Navg, 0) 6: end while • The ideal average, Navg is calculated. • BottomToTop allocates to every host, at most Navg iterations. • TopToBottom increases the allowed number of iterations for unbalanced hosts.

12. Example • Based on the Gauss Seidel method for(i = 2 to N-1) for(j = 2 to N-1) B[i, j] := (A[i -1,j]+ A[i + 1,j] + A[i, j -1]+ A[i, j + 1]) * 1/ά ; endfor endfor H2 H4 H4 H6 H6 H5 H5 H1 H2 H3 H1 H1 H3 H3 H7 H7 H2 H0 H2 H0 H4 H5 H6 H7 Array A Array B HHT

13. H0 H1 H2 H3 H4 H5 H6 H7 Example continued HHT

14. H0 30 H1 80 H2 80 H3 20 H4 40 H5 70 H6 40 H7 40 Example Assignment of initial iterations. Navg = 400/8 = 50 Maximum load on any node is 80. While the average is 50.

15. Example – Operation of BottomtoTop Navg = 400/8 = 50 60 10 H0 30 H0 50 30 0 50 H1 50 H1 80 H2 50 H2 80 H3 20 0 20 0 0 40 > Navg ? H5 70 H4 40 H5 50 H6 40 H7 40

16. Example – Operation of BottomtoTop Navg = 400/8 = 50 60 H0 50 H0 50 10 0 50 H1 50 H1 50 H2 50 H3 20 0 20 0 0 H4 40 H5 50 H6 40 H7 40

17. Example Toptobottom 60 55 50 45 40 Increase allowed Load, Navg to 55 H0 50 H0 55 5 10 0 Balanced 40 45 50 H1 55 H1 50 H2 55 H2 50 H3 20 0 15 20 0 0 Balanced H5 50 H4 40 H5 55 H6 40 H7 40

18. Example continued 40 H0 55 5 0 40 H1 55 H2 55 H3 20 0 15 0 0 H4 40 H5 55 H6 40 H7 40

19. Example continued 20 Increase allowed load to 60 H0 60 0 0 30 H1 60 H2 60 H3 20 0 10 0 0 H4 40 H5 60 H6 40 H7 40

20. Example continued 2 Increase allowed load to 66 H0 66 0 0 18 H1 60 H2 66 H3 20 0 4 0 0 H4 40 H5 66 H6 40 H7 40

21. Example continued 0 Increase allowed load to 72 H0 68 0 0 18 The HHT is now ‘balanced’ at the root node. Maximum load on any node is 68 (from 80). H1 60 H2 66 H3 20 0 4 0 0 H4 40 H5 66 H6 40 H7 40

22. Experimental Results • Two metrics were studied for multiple HHTs • Execution Time (EXE) • Standard deviation of workload (STD) • Two scenarios were studied • Default data decomposition + multiple HHTs • Default HHT + multiple decompositions

23. Experimental Results – (1/2)Default HHT + multiple decompositions STD for the different data decompositions with a default HHT. Overall finish time for the different data decompositions with a default HHT.

24. Experimental Results – (2/2)Default HHT + multiple decompositions STD for the different HHTs with a default data decompostion Overall finish time for the different HHT with a default data decomposition

25. Conclusion • Showed that load balancing is required in secure code partitioning • Proposed performance aware secure code partitioning to reduces the overall finish time. • Better load balancing compared to the original method is achieved as well.

26. Thank you Sri Hari Krishna Narayanan snarayan@cse.psu.edu