DOC PREVIEW
Berkeley COMPSCI 258 - HARDWARE SUPPORT FOR ENFORCING INFORMATION

This preview shows page 1-2-3-4-5-6 out of 19 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 19 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 19 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 19 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 19 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 19 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 19 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 19 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

HARDWARE SUPPORT FOR ENFORCING INFORMATION FLOW CONTROL ON MANYCORE SYSTEMSPARALLEL COMPUTING & THE FUTURESECURITYPROJECT GOALSRELATED WORKINFORMATION FLOW CONTROLHISTARMONDRIAN MEMORY PROTECTIONSlide 9OUR DESIGNRELABLINGPIPELINEMEMORY PROTECTION TABLEMETHODOLOGYOVERHEADSFUTURE/IN PROGRESS WORKUSES OF A TAGGED SYSTEMCONCLUSIONSREFERENCESHARDWARE SUPPORT FOR ENFORCING INFORMATION FLOW CONTROL ON MANYCORE SYSTEMSSarah BirdDavid McGroganPARALLEL COMPUTING & THE FUTUREParallel designs are emergingScaling increases transistor countsCannot extract any more ILP from programsSecurity is ImportantMobile DevicesEverything connected to the internetOpen Source CodeMore personal data on the netSECURITYCurrent Systems have only a couple rings of protectionAdding features to an application compromises the entire applicationPlug-ins in BrowsersDevice Drivers in Operating SystemsPROJECT GOALSProvide many levels of protectionReduce trusted codeMore easily verified Low Overhead in AreaCan’t afford to just tag everythingLow Overhead in PerformanceClients measure success in performance (security is still hard to quantify)Flexible SystemRELATED WORKFine-Grained ProtectionMondrian Memory Protection (MIT)Legba (New South Wales)Information Flow ControlHiStar (Stanford)Asbestos (UCLA, MIT, Stanford)Raksha (Stanford)Loki (Stanford)Dstar (Stanford)INFORMATION FLOW CONTROLProvide Labels on Processes, Data, Devices, etc.Restrict the flow of information from more secure labels to less labelsCan be done in hardware, software or bothHISTAROperating SystemUses Asbestos LabelsEnforces Information Flow Control in SoftwareMONDRIAN MEMORY PROTECTIONCompressed Protection Tables in MemoryProtection Check in Parallel with Standard PipelineProtection Lookaside Buffer functions caches protection resultsSidecars store protection for addressesPROJECT GOALSProvide many levels of protectionHiStar LabelsReduce trusted codeEnforce Protection in Hardware Low Overhead in AreaCompressed Protection Tables in MemoryLow Overhead in PerformanceCache Protection ChecksFlexible SystemPut Policies in SoftwareOUR DESIGNProtection TableMemoryNetwork InterfaceCache SystemTags Per Cache LinePipelineProtection CheckProtection Check CacheRELABLINGTwo Possible SolutionsLocal RelablingTakes advantage of localityGlobal RelablingDoesn’t need to be translated for different cpusReduces network trafficFinal Solution:Global Relabling with 16 bit tags16 extra bits for read requests and responses across the network16 extra bits per cache line in the cache systemPIPELINEProtection CheckCommitCommitTread ID Data Tag Protection Check1 57 1112 68 100Thread 1 PCThread 1 TagThread 2 PCThread 2 TagMEMORY PROTECTION TABLEFlat TableMore compressedInsert must slide down everythingCompletely flexible representationBinary Search to look upMultilevel TableSimple look up algorithmLess flexibleEasy insertMETHODOLOGYSimulate design using Simics with a simple memory hierarchyInsert delays in the memory hierarchy to represent the delays for protection lookupRun simple benchmarks to measure the worst case overheadOVERHEADS16 bits/read request = 33.3% overhead 16 bits/read response =1.56% overheadMemory Protection Table Lookup (3 extra memory accesses)/memory read = 300% overheadProtection Cache Miss (1 memory access)Protection Check Miss = runs the software handler (2000 cycles)Memory Overhead = ~6 %FUTURE/IN PROGRESS WORKCompare overheads with Original Histar System on a single coreDevelop a more realistic model of the protection system in SimicsAnalyze more realistic workloads for category usageUSES OF A TAGGED SYSTEMDebuggingDetecting wild writesArray bounds overflowsProfilingSecurityIsolate ProcessesProtect DataRestrict the flow of informationCONCLUSIONSSecurity is becoming increasingly importantEssential to reduce trusted code and isolate processes from each otherParallel is happeningLow over usage security systems are necessaryInformation Flow Control is a viable optionHardware support is necessary for performance Complex power may have negative power effectsREFERENCESNickolai Zeldovich, Silas Boyd-Wickizer, Eddie Kohler, and David Mazières. Making information flow explicit in HiStar. In Proceedings of the 7th Symposium on Operating Systems Design and Implementation, Seattle, WA, November 2006Nickolai Zeldovich, Silas Boyd-Wickizer, and David Mazières. Securing Distributed Systems with Information Flow Control. In Proceedings of the 5th Symposium on Networked Systems Design and Implementation, San Francisco, CA, April 2008Hari Kannan, Nickolai Zeldovich, Michael Dalton, Christos Kozyrakis. Architectural Support for Minimizing Trusted Code.Emmett Witchel, Junghwan Rhee, Krste Asanović, "Mondrix: Memory Isolation for Linux using Mondriaan Memory Protection", 20th ACM Symposium on Operating Systems Principles (SOSP-20) Brighton, UK, October 2005.Emmett Witchel, Josh Cates, and Krste Asanović, "Mondrian Memory Protection", Tenth International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS-X) , San Jose, CA, October 2002.Maxwell Krohn, Petros Efstathopoulos, Cliff Frey, Frans Kaashoek, Eddie Kohler, David Mazières, Robert Morris, Michelle Osborne, Steve VanDeBogart and David Ziegler. Make Least Privilege a Right (Not a Privilege). Proceedings of the 10th Workshop on Hot Topics in Operating Systems, Santa Fe, NM, June 2005.Petros Efstathopoulos, Maxwell Krohn, Steve VanDeBogart, Cliff Frey, David Ziegler, Eddie Kohler, David Mazières, Frans Kaashoek and Robert Morris. Labels and Event Processes in the Asbestos Operating System. Proceedings of the 20th Symposium on Operating Systems Principles, Brighton, United Kingdom, October 2005.Michael Dalton, Hari Kannan, Christos Kozyrakis, Raksha: A Flexible Information Flow Architecture for Software Security. Proceedings of the 34th Intl. Symposium on Computer Architecture (ISCA), San Diego, CA, June 2007.Adam Wiggins, Simon Winwood, Harvey Tuch and Gernot Hesier, Legba: Fast Hardware Support for Fine-Grained


View Full Document

Berkeley COMPSCI 258 - HARDWARE SUPPORT FOR ENFORCING INFORMATION

Documents in this Course
Load more
Download HARDWARE SUPPORT FOR ENFORCING INFORMATION
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view HARDWARE SUPPORT FOR ENFORCING INFORMATION and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view HARDWARE SUPPORT FOR ENFORCING INFORMATION 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?