NVIDIA Falcon Security

From 60b67c31fcad6d0dc9603a034994a12efe3d5202 Mon Sep 17 00:00:00 2001 From: John Hubbard Date: Sun, 21 Apr 2019 17:09:24 -0700 Subject: Open doc files, version 1 of everything This copies over files from: http://download.nvidia.com/open-gpu-doc/ with a few overrides from local, as-yet-to-be-published files (generally just a file suffix and licensing tweak). Here's the script that was used to create this commit: wget -r http://download.nvidia.com/open-gpu-doc/ mv download.nvidia.com/open-gpu-doc/* . rm -rf download.nvidia.com/ find . -name index.html | xargs rm -f find . -name Thumbs.db | xargs rm -f find . -type f | grep -v \.git | xargs file | grep CRLF | cut -f1 -d: | xargs dos2unix for f in `find . -name 1 | cut -f2 -d "/"`; do pushd $f; mv 1/* .; popd; done find . -name 1 | xargs rmdir rm -rf Host-Fifo/volta/gv100 mkdir -p Host-Fifo/volta/gv100 cp $sw/docs/Public_Devel_Docs/release/Host-Fifo/volta/gv100/* Host-Fifo/volta/gv100/ rm Display-Ref-Manuals/gv100/dev_display.ref cp $sw/docs/Public_Devel_Docs/release/Display-Ref-Manuals/1/gv100/dev_display.ref \ Display-Ref-Manuals/gv100/dev_display.ref.txt git add . git mv DCB/DCB-4.0-Specification.html DCB/DCB-4.x-Specification.html git reset HEAD Display-Class-Methods/2 git reset HEAD DCB/2 git commit Reviewed-by: Andy Ritger --- Falcon-Security/Falcon-Security.html | 840 +++++++++++++++++++++++++++++++++++ 1 file changed, 840 insertions(+) create mode 100644 Falcon-Security/Falcon-Security.html (limited to 'Falcon-Security') diff --git a/Falcon-Security/Falcon-Security.html b/Falcon-Security/Falcon-Security.html new file mode 100644 index 0000000..4b64d0d --- /dev/null +++ b/Falcon-Security/Falcon-Security.html @@ -0,0 +1,840 @@ + + + + + +NVIDIA Falcon Security + + + + + +

NVIDIA GPUs embed several microprocessors based on a custom architecture called +"Falcon". Starting with the Maxwell family of GPUs, these microprocessors are +changing to be able to better protect the hardware from being misprogrammed.

Falcon security modes

A Falcon microprocessor supporting advanced security modes can run in one of +three modes. Not all Falcon microprocessors on a GPU support all modes.

+
+Non-secure (NS). In this mode, functionality is similar to Falcon + architectures before security modes were introduced (pre-Maxwell), but + capability is restricted. In particular, certain registers may be + inaccessible for reads and/or writes, and physical memory access may be + disabled (on certain Falcon instances). + This is the only possible mode that can be used if you don’t have + microcode cryptographically signed by NVIDIA. +
+
+
+Heavy Secure (HS). In this mode, the microprocessor is a black box — it’s + not possible to read or write any Falcon internal state or Falcon registers + from outside the Falcon (for example, from the host system). The only way to + enable this mode is by loading microcode that has been signed by NVIDIA. + (The loading process involves tagging the IMEM block as secure, writing the + signature into a Falcon register, and starting execution. The hardware will + validate the signature, and if valid, grant HS privileges.) +
+
+
+Light Secure (LS). In this mode, the microprocessor has more privileges than + NS but fewer than HS. Some of the microprocessor state is visible to host + software to ease debugging. The only way to enable this mode is by HS + microcode enabling LS mode. Some privileges available to HS mode are not + available here. LS mode is introduced in GM20x. +
+

GM10x

The intent for GM10x is to protect fuses and ROM from being written by +incorrect or malicious software.

This is implemented by preventing access to select GPU registers from anything +other than a Falcon running in a secure mode.

GM20x

The intent for GM20x is to improve upon the GM10x implementation and add some +protection to the configuration of the hardware thermal shutdown mechanism.

In addition to the registers protected by GM10x:

+
+Thermal shutdown registers are protected and can only be written from a + secure microprocessor context. These registers can be broken down into two + categories: +
+
- +
  +Thermal sensor setup +
  +
- +
  +The temperature beyond which hardware triggers a forced shutdown to + prevent damage. +
  +
+
+
+I²C bus C writes are restricted to a secure context, to prevent + misprogramming thermal sensors. +
+
+
+A new mechanism is introduced to prevent microcode tampering after load. This + is achieved by placing microcode in a write-protected region of memory. +
+
+
+Physical memory access restrictions are introduced. On all Falcons other + than PMU (the "kitchen sink" Falcon) and DPU (the Falcon that services + display), microprocessors running in NS mode will be unable to access + physical memory (they may use virtual memory exclusively). In particular, + this includes all microprocessors which perform work directly in response to + userspace requests. +
+
+
+Devinit scripts are signed and executed on the PMU so that these scripts can + configure protected registers like thermal shutdown parameters. +
+

+ + + -- cgit v1.2.3