Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Securing the Future of Safety and Security of Embedded Software

511 views

Published on

SPARK / Ada Journey to Adoption
Daniel Rohrer, VP SW Product Security, NVIDIA – November 21, 2019

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Securing the Future of Safety and Security of Embedded Software

  1. 1. Daniel Rohrer, VP SW Product Security, NVIDIA – November 21, 2019 SPARK / ADA JOURNEY TO ADOPTION
  2. 2. 2 SAFE HARBOR Forward-Looking Statements Except for the historical information contained herein, certain matters in this presentation including, but not limited to, statements as to: our strategies, growth, position, opportunities, goals, and continued expansion; the performance and benefits of our products and technologies; the impact of macro trends on software security; the benefits and impact of, and adoption path for, Ada/SPARK and AdaCore; and other predictions and estimates are forward-looking statements within the meaning of the Private Securities Litigation Reform Act of 1995. These forward-looking statements and any other forward-looking statements that go beyond historical facts that are made in this presentation are subject to risks and uncertainties that may cause actual results to differ materially. Important factors that could cause actual results to differ materially include: global economic conditions; our reliance on third parties to manufacture, assemble, package and test ourproducts; the impact of technological development and competition; development of new products and technologies or enhancements to our existing product and technologies; market acceptance of our products or our partners’ products; design, manufacturing or software defects; changes in consumer preferences and demands; changes in industry standards and interfaces; unexpected loss of performance of our products or technologies when integrated into systems and other factors. For a complete discussion of factors that could materially affect our financial results and operations, please refer to the reports we file from time to time with the SEC, including our Form 10-K for the annual period ended January 27, 2019 and our Form 10-Q for the quarterly period ended October 27, 2019. Copies of reports we file with the SEC are posted on our website and are available from NVIDIA without charge. These forward-looking statements are not guarantees of future performance and speak only as of November 21, 2019, based on information currently available to us. Except as required by law, NVIDIA disclaims any obligation to update these forward-looking statements to reflect future events or circumstances.
  3. 3. 3 NVIDIA JOURNEY TO FORMALISM ADACORE Learnings & the Journey Ahead AGENDA
  4. 4. 4 BUSINESS CONTEXT Increasingly complex system (consumer, embedded, auto, robotics, medical, HPC) Increasing criticality (IP Risk, Life safety/ISO26262, physical attacks) Attacker trending lower in technology stack Ecosystem tooling not keeping pace with attacks Human and Human-in-loop techniques not scaling Increasing cost to update MACRO TRENDS DRIVING RISK AND INNOVATION
  5. 5. 5 BUSINESS CONTEXT Increasingly complex system (consumer, embedded, auto, robotics, medical, HPC) Increasing criticality (IP Risk, Life safety/ISO26262, physical attacks) Attacker trending lower in technology stack Ecosystem tooling not keeping pace with attacks Human and Human-in-loop techniques not scaling Increasing cost to update NVIDIA TAKES SECURITY AND SAFETY VERY SERIOUSLY WHAT ABOUT THIS PROBLEM CAN WE CHANGE? MACRO TRENDS DRIVING RISK AND INNOVATION
  6. 6. 6 START WITH FIRST PRINCIPLES What key factors drive outcomes? Human Factors Ambiguity / Decidability of language Effectiveness of Tooling Ecosystem support Measurable
  7. 7. 7 START WITH FIRST PRINCIPLES What key factors drive outcomes? Human Factors Ambiguity / Decidability of language Effectiveness of Tooling Ecosystem support Measurable Skilled practitioners are hard to find (ISC)2 reports ~500,000 workforce shortage for cybersecurity in US alone Human time scales are too slow to meet market demands already. What strategies can amplify the human capital we already have?
  8. 8. 8 What can help us address intrinsic development and language shortfalls? START WITH FIRST PRINCIPLES What key factors drive outcomes? Human Factors Ambiguity / Decidability of language Effectiveness of Tooling Ecosystem support Measurable https://cve.mitre.org/(Nov 10)
  9. 9. 9 START WITH FIRST PRINCIPLES What key factors drive outcomes? Human Factors Ambiguity / Decidability of language Effectiveness of Tooling Ecosystem support Measurable Decidability limits static analysis effectiveness What tool and test strategies can generate higher confidence assertions?
  10. 10. 10 START WITH FIRST PRINCIPLES What key factors drive outcomes? Human Factors Ambiguity / Decidability of language Effectiveness of Tooling Ecosystem support Measurable Availability of off the shelf fuzzing and dynamic analysis is limited. These often don’t meet safety standards. How can I meet business requirements without diluting product development investment?
  11. 11. 11 START WITH FIRST PRINCIPLES What key factors drive outcomes? Human Factors Ambiguity / Decidability of language Effectiveness of Tooling Ecosystem support Measurable We improve what we measure Prefer leading indicator to trailing indicators. What methodologies increase our ability to measure risk and safety outcomes?
  12. 12. 12 ADOPTION JOURNEY
  13. 13. 13 ADOPTION PATH BUILDING A BUSINESS CASE How much are we investing TODAY? How much will we NEED to invest TOMORROW? Is it POSSIBLE to address this with our current strategy? PICK A SOLUTION PICK A TARGET ADOPT NEW LANGUAGE AND DEVELOPMENT MODEL
  14. 14. 14 PICK A SOLUTION Language (Ambiguity/Decidability) Credible Ecosystem Emphasize ‘provability’ over ‘test/verif’ Meets scaling needs Responsive ADA/SPARK & ADACORE Strongly typed, decidable backed by formal methods aligned with our integrity goals Compatible feature set Had C linkability.
  15. 15. 15 PICK A SOLUTION Language (Ambiguity/Decidability) Credible Ecosystem Emphasize ‘provability’ over ‘test/verif’ Meets scaling needs Responsive ADA/SPARK & ADACORE Mature language broad ecosystem and commercial support upstream OSS presence safety certifiable with success in adjacent markets Partner willing to support short term and long term goals.
  16. 16. 16 PICK A SOLUTION Language (Ambiguity/Decidability) Credible Ecosystem Emphasize ‘provability’ over ‘test/verif’ Meets scaling needs Responsive ADA/SPARK & ADACORE Contract design and proof moves makes implicit requirements explicit. Effective outcome is to move security left Supports our goal of formalism within safety programs.
  17. 17. 17 PICK A SOLUTION Language (Ambiguity/Decidability) Credible Ecosystem Emphasize ‘provability’ over ‘test/verif’ Meets scaling needs Responsive ADA/SPARK & ADACORE I can buy machines, no experts available to hire Eliminates other overheads (test, fuzzing) Can re-invest human capital back into product
  18. 18. 18 PICK A SOLUTION Language (Ambiguity/Decidability) Credible Ecosystem Emphasize ‘provability’ over ‘test/verif’ Meets scaling needs Responsive ADA/SPARK & ADACORE Partner already invested in the ecosystem. Was able to engage at deep technical level, Familiar with core challenges Highly responsive
  19. 19. 19 PICK A TARGET Omnipresent (Consumer, Enterprise, IOT/Automotive, Mobile, etc) Executes at very high privilege impacting critical security decisions Attacker trends shifting to firmware and HW targets Generally high cost to remediate Predominantly C development Smaller code bases and teams to ramp Aligned to increased customer sensitivity to persistence attacks FIRMWARE IS IDEAL!
  20. 20. Dhawal Kumar (Principal System Software Engineer) 21-Nov-2019 SECURING THE FUTURE OF SAFETY AND SECURITY OF EMBEDDED SOFTWARE
  21. 21. 22 Firmwares and their environment What is SPARK? Alternatives considered (and dismissed) POC, its conclusions and concerns Benefits and summary AGENDA
  22. 22. 23 FIRMWARES AND THEIR ENVIRONMENT
  23. 23. 24 FIRMWARES AND THEIR ENVIRONMENT Falcon NVIDIA proprietary ISA CCG to convert SPARK to C RISC-V Public ISA Native compiler 2 kinds of Security Processors Secure boot DRM Video decoding Clock and voltage programming … Security and Safety Critical Firmwares Security Processors Run On
  24. 24. 25 WHAT IS SPARK?
  25. 25. 26 INTRO TO SPARK Large subset of Ada programming language Most notable difference compared to Ada = Reduced flexibility on pointer usage Paradigms close to C/C++ (imperative, procedural or object oriented, programming in the large…) Additional capabilities for specification and verification ➔ Can “prove” programs No undefined behavior
  26. 26. 27 SPARK: BASIC VERIFICATIONS My_Array (Index) := (X * Y) / Z; Index out of bounds of My_Array? Z potentially 0? (X * Y) potentially overflow? (X * Y) / Z potentially overflow? (X * Y) / Z potentially out of range? Index initialized? X, Y, Z initialized? My_Array [Index] = (X * Y) / Z;Equivalent C
  27. 27. 28 SPARK: ADVANCED VERIFICATIONS - 1 Replace defensive code with contracts (save space, no need to simulate error condition that may never happen) Simple properties can be specified and verified, e.g. mutex release after acquisition procedure Next (A : in out Array; Iterator : in out Integer; Stop : Value) with Pre => Iterator in A'Range; procedure Perform_Critical_Operation with Post => Mutex.Is_Taken'Old = Mutex.Is_Taken;
  28. 28. 29 Functional requirement can be specified and verified SPARK: ADVANCED VERIFICATIONS - 2 procedure Move_Protection_Region (From_Start, From_End, To_Start, To_End : Integer) with Post => (for all Byte in Memory'Range => (if Byte in From_Start .. From_End and not Byte in To_Start .. To_End then Memory (Byte).Erased -- Blue erased else not Memory (Byte).Erased)); -- Green, pink, orange not erased From To Memory'Range
  29. 29. 30 ALTERNATIVES: BACKGROUND STORY
  30. 30. 31 NVIDIA GOALS - SECURITY Make a major difference to security robustness story Existing tools and techniques such as static analysis, fuzzing, compiler hardening haven’t been moving the needle sufficiently Desire to put certain class of problems to rest for good Reduce the reliance on humans such as reviewers and developers Humans get tired and less effective as LOC rises
  31. 31. 32 NVIDIA GOALS – SAFETY (ISO-26262) Ensure that new language, or tool Does not slow NVIDIA down on safety certification New language or tool automatically implies some slowdown Preferably helps make it easier to do safety certification Less effort Ticks more checkboxes in ISO-26262 spec Is acceptable to NVIDIA’s safety assessor
  32. 32. 33 NVIDIA GOALS - PRACTICALITY Ensure that new language or tool Is practical enough to be adopted by NVIDIA Can’t expect typical NVIDIA engineer to be an expert in formal methods, do proofs by hands etc Can’t expect NVIDIA to build toolchain to compile SPARK for falcon (proprietary ISA). Hands full already with C Has good support system Commercial backing for anything new is practically must have Does not add unreasonable run time burden Memory footprint Performance
  33. 33. 34 ALTERNATIVES CONSIDERED
  34. 34. 35 ALTERNATIVES - MAJOR Frama-C (+) Nearly all the same capabilities as SPARK (at least on paper) (+) It’s “C” (-) Need to learn the specification/contract language (ACSL) (-) Requires refactoring/rewrite to be prover friendly (-) “C” means inherently weak type system (-) Only partial commercial support, no safety certification Rust (+) Active community (+) Memory safety (-) Does not address many class of vulnerabilities (e.g. CWE) that SPARK or Frama C do (-) No ability to write user contracts (program specific requirements) (-) High memory footprint (based on findings reported in Wookey paper) (-) Does not have a formalized spec (-) No commercial vendor, no near term plan for safety certification
  35. 35. 36 ALTERNATIVES – LESSER KNOWN Ivory (-) Substantially different language from C. So, wouldn’t be better than SPARK in terms of learning curve (-) Not enough data points about commercial support or usage while Ada had plenty with SPARK gaining traction
  36. 36. 37 PROOF OF CONCEPT
  37. 37. 38 POC: GOALS - 1 Understand language and toolchain Gain hands on experience Determine the difficulty and learning curve for others Establish ROI Demonstrate AORTE for two high value code bases Determine engineering cost to get to AORTE Evaluate support system Establish how to surmount challenges not encountered during POC (commercial support, stackoverflow, books, etc) Understand efficacy and latency of Adacore’s support system
  38. 38. 39 POC: GOALS - 2 Run time overhead Code bloat Performance
  39. 39. 40 POC: CODE BASES Applications Baremetal app acting as root of trust for code running on several security processors App under RTOS for handling re-size of security protection regions Both security critical
  40. 40. 41 MAIN ENGINEERING CONCERNS I can’t find examples on the Internet The code size may increase The prover is difficult to understand Not all tools support Ada It’s difficult to find trained engineers There is a lot of code already in C
  41. 41. 42 MAIN ENGINEERING CONCERNS & MITIGATIONS I can’t find help on the Internet The code size may increase The prover is difficult to understand Not all tools support Ada It’s difficult to find trained engineers There is a lot of code already in C Support services are available Alternative tools are available for most needs Engineers can be trained in house C can be interfaced with Ada & SPARK The increase is manageable with switches and re-write In-house expertise is developed No silver bullet here There is a cost to adopting SPARK
  42. 42. 43 POC CONCLUSION
  43. 43. 44 POC: CONCLUSIONS - SECURITY Nearly all code can be written in SPARK. This would make a major impact to security robustness Reliance on humans can indeed be lessened given The soundness of SPARK Ability to write user contracts
  44. 44. 45 POC: CONCLUSIONS - SAFETY Safety was not a target during POC but subsequent investigation demonstrated that Ada/SPARK Tick more checkboxes in ISO-26262 spec Are acceptable (in fact preferred) to safety assessor provided developers have sufficient training Can be safely mixed with C if needed May not change “effort” due to one time costs such as engineer ramp up and effort spent discovering equivalent tools and processes for Ada/SPARK
  45. 45. 46 POC: CONCLUSIONS – PRACTICALITY Practical enough to be a candidate for adoption in security and safety critical applications Support system is world class. Nvidia can count on Adacore Low latency Focused on solving customer problems Need additional memory Compiler switches (-gnatp, no –gnata, possibly -flto) are necessary for memory constrained targets Hand optimizations may be necessary Some areas such as CCG may still produce code that could have been optimized but isn’t being
  46. 46. 47 SPARK BENEFITS AND SUMMARY
  47. 47. 48 KEY SPARK BENEFITS “If it proves, it works” Reviewers can focus on complex problems Numerous CWEs put to rest for good Less effort in debugging Developers become quality engineers No MISRA-C overhead It is worth it
  48. 48. 49 NVIDIA SUMMARY SPARK is now used for NVIDIA security- and safety-critical firmware applications Software expected to be productized in 2020 Addresses scalability (of critical expertise) concerns Not entirely free of challenges. Recommend picking the targets wisely
  49. 49. 51 © 2019 NVIDIA Corporation. All rights reserved. NVIDIA and the NVIDIA logo are trademarks and/or registered trademarks of NVIDIA Corporation in the U.S. and other countries. Other company and product names may be trademarks of the respective companies with which they are associated.

×