Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for Light Secure Mode and Heavy Secure Mode emulation #12

Draft
wants to merge 41 commits into
base: main
Choose a base branch
from

Conversation

vbe0201
Copy link
Owner

@vbe0201 vbe0201 commented Sep 3, 2020

As per title, this PR is a WIP effort to add support for the different Falcon security modes.

Synopsis

Starting from the Maxwell generation of NVIDIA GPUs, the Falcons supports three different execution modes at runtime which orchestrate the amount of privileges the Falcon has in accessing registers and memory. These modes namely are:

  • Non-secure mode (NS): The only possible mode that can be used without code that is cryptographically signed by NVIDIA. Functionality is similar to pre-Maxwell Falcons, except that they can be further restricted in their capability to access certain registers and/or do DMA.

  • Light Secure mode (LS): Can be explicitly enabled from Heavy Secure mode context. This mode grants more privileges than NS but fewer than HS and is mostly used for debugging purposes rather than in production code.

  • Heavy Secure mode (HS): Granted by hardware after a successful MAC comparison upon jumping to a code block tagged as secure. In this mode, the Falcon acts similar to a black box, as NVIDIA likes to say. Most of the internal state is inaccessible from external sources (such as the host system) while the Falcon operates on the highest amount of privileges possible.

  • Falcon ROM mode: During certain cryptographic operations, the Falcon jumps into the Falcon bootrom located in an internal ROM segment that is hidden away from running code. Due to debugging functionality not working on it, it effectively is a shittier-HS-mode-but-you-can-execute-csigauth (cc SciresM)

faucon-emu will want to support these modes of execution along with the ability to provide custom keys and the corresponding functionality to disassemble crypto commands in faucon-asm.

More Technical Synopsis

Falcons that support cryptographic operations are referred to as secretful units and come with a Security Co-Processor (SCP) which processes incoming crypto commands from the main circuity. The SCP is subdivided into different hardware blocks, each of them taking care of a different task to keep the cryptosystem as a whole intact:

  • CMD: The hardware block that receives Falcon crypto commands and decodes them into SCP instructions

  • LOAD: A block that handles DMA load operations between the Falcon and the internal SCP state (registers and crypto stream)

  • STORE: A block that handles DMA store operations between the Falcon and the internal SCP state (registers and crypto stream)

  • SEQ: A block that records, stores, and carries out sequences of Falcon crypto commands as macros

  • CTL: A block that oversees and controls certain state and features of the SCP

  • RND: A block that is responsible for hardware-accelerated random number generation

  • RNG: A block that controls and wraps the functionality of the RND block

  • AES: Hardware-accelerated 128-bit AES implementation in ECB mode

faucon-emu introduces a structure Scp that is owned by Cpu and emulates the functionality of the above blocks. The focus is not accurate LLE but to have abstract representations of all the features which interact nicely with the core logic by emulating the relevant Falcon concepts. Extending the Memory structure by a ROM section (plus adding the relevant flag bit for locking it down) along with some poor Falcon assembly stubs reimplementing the desired portions of it for accurately maintaining state modifications on the crypto registers.

Steps

  • Document and add support for parsing the SCP-related configuration entries

  • Extend faucon-asm-derive and faucon-asm to support crypto instruction disassembling

    • size: 0x3, a: 0x3, b: 0x5, subopcode: 0x3C for CCMD
    • 3rd and 4th instruction byte should be interpreted as an u16 crypto pair: insn[3] << 8 | insn[2]
    • extracting the crypto opcode: crypto_pair >> 0xA & 0x1F
    • extracting instruction immediates: crypto_pair >> 4 & 0x3F
    • extracting instruction registers: crypto_pair & 0xF and/or crypto_pair >> 0x4 & 0xF
  • Add support for crypto instruction emulation in faucon-emu using Scp (this will cover up most of the important Falcon SCP concepts, such as crypto registers, ACL, crypto streams, SEQ macroing)

  • Add DMA support for Falcon <-> SCP

  • Implement ROM mode with bootrom code stubs (?)

  • Implement HS authentication including secure code pages in Memory

  • Implement SCP MMIO registers

  • Add LS functionality

  • Add useful faucon CLI commands, such as auth signature generation/validation and code encryption

Base automatically changed from master to main March 24, 2021 14:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant