Daniel Rohrer, VP of Software Product Security at NVIDIA, discussed NVIDIA's journey to adopting the SPARK subset of the Ada programming language and the AdaCore tooling for improving software security and safety. NVIDIA was motivated by increasing complexity of systems, criticality of failures, and limitations of existing techniques. They selected SPARK and AdaCore due to the decidable nature of the language, credible ecosystem, emphasis on provability over testing, ability to scale, and responsiveness of AdaCore. NVIDIA piloted the use of SPARK on firmware to gain security and safety benefits while targeting a small codebase. The presentation covered benefits of SPARK for verification and alternatives considered.

1. Daniel Rohrer, VP SW Product Security, NVIDIA – November 21, 2019
SPARK / ADA JOURNEY
TO ADOPTION

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
NVIDIA JOURNEY TO FORMALISM
ADACORE
Learnings & the Journey Ahead
AGENDA

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
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
START WITH FIRST PRINCIPLES
What key factors drive outcomes?
Human Factors
Ambiguity / Decidability of language
Effectiveness of Tooling
Ecosystem support
Measurable

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
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
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
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
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
ADOPTION JOURNEY

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
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
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
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
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
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
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!

21. Dhawal Kumar (Principal System Software Engineer)
21-Nov-2019
SECURING THE FUTURE OF
SAFETY AND SECURITY OF
EMBEDDED SOFTWARE

22. 22
Firmwares and their environment
What is SPARK?
Alternatives considered (and dismissed)
POC, its conclusions and concerns
Benefits and summary
AGENDA

23. 23
FIRMWARES AND THEIR
ENVIRONMENT

24. 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

25. 25
WHAT IS SPARK?

26. 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

27. 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

28. 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;

29. 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

30. 30
ALTERNATIVES:
BACKGROUND STORY

31. 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

32. 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

33. 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

34. 34
ALTERNATIVES
CONSIDERED

35. 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

36. 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

37. 37
PROOF OF CONCEPT

38. 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

39. 39
POC: GOALS - 2
Run time overhead
Code bloat
Performance

40. 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

41. 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

42. 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

43. 43
POC CONCLUSION

44. 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

45. 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

46. 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

47. 47
SPARK BENEFITS AND
SUMMARY

48. 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

49. 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

51. 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.