by Dhawal Kumar, 13-Nov-2019. AdaCore Tech Days

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

4. 4
WHY SPARK FOR
FIRMWARE?

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

12. 12
SPARK: A PROBLEM
SOLVER

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

24. 24
DEVELOPMENT
CHALLENGES

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

28. 28
ADOPTION STRATEGY

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.