Spark / Ada for Safe and Secure Firmware Development
2 likes385 views
The document discusses using SPARK for secure and safe firmware development. It notes that firmware is written mostly in C, which is prone to security vulnerabilities. SPARK aims to address this by using formal verification methods, improved static analysis, and developer contracts to find and prevent bugs. The document outlines NVIDIA's usage of SPARK for security processors and safety-critical code. While SPARK faces challenges regarding adoption due to its differences from C, NVIDIA is taking a phased approach to adoption by starting with proof of concepts and increasing usage over time for its most critical firmware components.
![14
SPARK: A PROBLEM SOLVER - 1
Static analysis
High quality
Low noise
[Peer] Reviews (automated)
Machine never gets tired
Reviewers freed up to focus on more important parts ➔ Scalability problem less severe](https://image.slidesharecdn.com/sparkadaforfirmwarethenvidiastory-11-13-2019-191212154246/85/Spark-Ada-for-Safe-and-Secure-Firmware-Development-14-320.jpg)
Spark / Ada for Safe and Secure Firmware Development
- 1. Dhawal Kumar, 13-Nov-2019 SPARK / ADA FOR SAFE AND SECURE FIRMWARE DEVELOPMENT
- 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, and continued expansion; the performance and benefits of our products and technologies; the state of affairs of firmware and C; consequences of software vulnerability; the benefits and impact of, development challenges with, and adoption path for, SPARK; 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 our products; 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 13, 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 Why SPARK for firmware? Usage of SPARK at NVIDIA Learn Adoption Path AGENDA
- 5. 5 FIRMWARE: STATE OF AFFAIRS Omnipresent (PCs, supercomputers, IOT devices, cellphones, cars etc) Executes at elevated privilege (higher than rich OS) Attractive target for attackers to implant malware (ransomware, rootkit) With OS security advancements, focus shifted to firmware Developed predominantly in C
- 6. 6 C: STATE OF AFFAIRS Security vulnerabilities continue to happen (or recur) Memory corruption vulnerabilities (Buffer overflow, ROP etc) Numeric truncation Typos in ifdefs (ifdef READ_ABLE vs ifdef READABLE) Regressions (security regressions usually invisible) https://cve.mitre.org/ (Nov 10)
- 7. 7 C: DID WE UNDER INVEST? Security vulnerabilities continue to happen despite Usage of static analysis tools such as coverity Compiler hardening techniques such as stack canary, address sanitizer HW countermeasures Negative tests (ex: fuzzing) Peer reviews
- 8. 8 C: WHY DO PROBLEMS HAPPEN - 1 Static analysis tools Do not cover enough Get noisy as we try to extract more out of them and still fall short HW countermeasures Expensive Can’t solve all issues
- 9. 9 C: WHY DO PROBLEMS HAPPEN - 2 Fuzzing Very time consuming Tricky for firmware (crashes are costly) Peer reviews Not enough reviewers (practically unsolvable scalability problem) Reviewers may not have domain knowledge Humans get tired and less effective as code grows
- 10. 10 C: WHY DO PROBLEMS HAPPEN - 3 Developers Lack training (difficult to find courses on FW let alone FW security) Lack the time for training Lack the mindset Attackers are getting smarter Tools for reverse engineering becoming cheaper and widely available
- 11. 11 CONSEQUENCES OF VULNERABILITY Even a single incident could be disastrous Millions of $s of penalty Product recall Man years lost in IR (Incident Response) Brand damage Lost sales Lives lost
- 13. 13 SPARK A language and a set of tools Language is a large subset of Ada Tool: GNATprove Formal Verification Built in goodness: AORTE / Silver User contracts
- 14. 14 SPARK: A PROBLEM SOLVER - 1 Static analysis High quality Low noise [Peer] Reviews (automated) Machine never gets tired Reviewers freed up to focus on more important parts ➔ Scalability problem less severe
- 15. 15 SPARK: A PROBLEM SOLVER - 2 HW countermeasures No need to pay (for some of them) And yet better results Fuzzing No fuzzing required Significant machine hours savings Reduced time to market
- 16. 16 SPARK: A PROBLEM SOLVER - 3 Developers Don’t need to know or test for many classes of attack Gets even better with SPARK contracts Regressions reduced
- 17. 17 USAGE OF SPARK AT NVIDIA
- 18. 18 USAGE: TARGETS SPs (Security Processors) Falcon RISCV Hardware Targets (Platforms) Security critical ucodes Safety (ISO-26262) critical ucodes Software Targets
- 19. 19 WHAT DOES SP LOOK LIKE? CPU IMEM DMEM SHA AES
- 20. 20 WHERE ARE THESE SPs? C R O S S B A R SP SP SP Graphics / Compute E E P R O M Internal Bus External Bus GPU Board FB Board / Die
- 21. 21 DETAILED SP USAGE Secure boot Video decoding DRM Power management Clock and voltage programming And more...
- 22. 22 HW TARGET: VARIATIONS RISCV is brand new, falcon has been around since over a decade Transition from falcon to RISCV underway and will take time RISCV can address larger IMEM and DMEM Does not mean space constraints have disappeared entirely (low power RAMs, EEPROM, boot perf) RISCV uses native compiler while falcon uses CCG
- 23. 23 SW TARGET: SAMPLE USER CONTRACTS Simple / Mid level If mutex has been acquired, it shall be released under all exit paths Tainted data can not be consumed without sanitization (abstraction + contracts) Advanced Memory model: Whenre-sizing a protection region, every byte that was previously Part of protection region but no longer is, shall be scrubbed Not part of protection region, shall stay unchanged
- 25. 25 DEVELOPMENT CHALLENGES - HW Require highly optimized code Space constraints (IMEM/DMEM, Low power RAMs, EEPROM) Performance constraints
- 26. 26 DEVELOPMENT CHALLENGES – SPARK - 1 New language (for Nvidia) Need to find equivalent of every tool / trick being used with C Safety cert makes it furthermore challenging Need to study specs such as Cert-C and MISRA to craft equivalent rules + checkers Small community Lack of reviewers (“we don’t know what we don’t know”) Engineering efficiency impacted
- 27. 27 DEVELOPMENT CHALLENGES – SPARK - 2 Bit fields (Ada records converted to bit fields by CCG) Not portable in C Unbearable code bloat ➔ One of the grounds for SPARK rejection in a potential use case Lack of support in popular IDEs (ex: Visual Studio) Additional learning curve ➔ displeasure
- 29. 29 ADOPTION PATH POC (Proof Of Concept) with handholding and mentorship Ramping up on more FWs under mentorship Started with boot firmware on falcon (but not all parts) Added RISCV bootrom Hope to convert more critical components from C to SPARK Don’t expect to convert all FWs (not practical in near future)
- 30. 30 SPARK SUMMARY Very appealing for Security and safety critical applications Addressing scalability concerns (of critical expertise) Not entirely free of challenges. So, pick the targets wisely
- 32. 32 © 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.