Developer Setup#

Onboarding#

1. Setup the docker container#

The development of the SDK is done in a local docker container. There is a helper script under scripts/dev-env.sh. Once docker is installed, the developer can use that script to create a docker container with all the dependencies installed. Run the script without any options to see the help.

$ ./scripts/dev-env.sh
Usage: ./scripts/dev-env.sh {setup|start|stop|clean|status|shell}
Manages the nv-attest development Docker environment.

Commands:
  setup    Builds the Docker image 'nvattest-dev-image' and sets ownership
           of '<project directory>' for user '<your user>' (requires sudo).
  start    Starts the Docker container 'nv-attest-dev-container' in the background.
           If stopped, restarts the existing container.
  stop     Stops the running Docker container 'nv-attest-dev-container'.
  clean    Stops and removes the container 'nv-attest-dev-container',
           then removes the image 'nvattest-dev-image'.
  status   Shows the status of the container 'nv-attest-dev-container'.
  shell    Executes an interactive bash shell in the running container.

A typical workflow would be like:

./dev-env.sh setup
./dev-env.sh start
./dev-env.sh shell
# do some work
./dev-env.sh stop

# to nuke the container
./dev-env.sh clean # need to run setup again after this

VSCode has support to connect to docker containers (its called remote explorer). This can make development significantly easier.

The script has a shell command which mounts the attestation-sdk directory in the container. The following steps can be done after shelling into the container.

Note: make sure you run git commands from your host machine, not the docker container as the git configuration (ssh-keys etc) will not be available in the docker container.

2. Source the helper scripts#

To make following steps easier, source the helper script:

source /attestation-sdk/nv-attestation-sdk-cpp/scripts/activate.sh

This script will update your path so that other scripts can be invoked from anywhere in the container.

3. Build the SDK#

The output of the following command is the library libnv_attestation_sdk.dylib or libnv_attestation.so

make build-sdk # see make help for more info

See the cmake file for the full list of available options

Note: when cmake is run the first time, it caches settings in CMakeCache.txt in the build folder (and in the root folder of the project). If you modify any of those settings, you need to rm the file for cmake to pick up the new changes. If there are any issues with cmake, clear these cache files in the build and the root folder.

4. VS Code Integration#

By using DCMAKE_EXPORT_COMPILE_COMMANDS=ON, cmake will produce build/compile_commands.json file. Modify settings.json in VS Code settings (workspace settings) as follows:

"C_Cpp.default.compileCommands": "${workspaceFolder}/build/compile_commands.json",
"C_Cpp.codeAnalysis.clangTidy.enabled": true,
"C_Cpp.codeAnalysis.clangTidy.useBuildPath": true

VSCode will use this to provide language server features, including an integration with clang-tidy for linting.

Debugging#

  • If you want to debug a dependency, make sure that you have the installed version of the dependency with debug symbols enabled, otherwise it is not possible to step through code in the dependency. More details will be added here once the exact steps for this are known.

This is an example launch config to debug in vscode:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Debug Test Executable",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/build/integration-tests/nv-attestation-unit-tests",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}/build",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                },
                {
                    "description": "Set disassembly flavor to Intel",
                    "text": "-gdb-set disassembly-flavor intel",
                    "ignoreFailures": true
                },
            ],
            "preLaunchTask": "build",
            "miDebuggerPath": "/usr/bin/gdb"
        }
    ]
}

This will not work in cursor because it modifies the python environment variables and gdb depends on Python. However this works perfectly in VS Code.

Note: This is for debugging the test executable that is built in the CMake file. For debugging unit tests, the launch configuration will have to be different. This readme will be updated once the unit test framework is set up.

Testing#

Prereqs#

  • Install Dev dependencies

make install-dev-deps

The unit-tests folder contains all the tests. Some of the tests also work as “integration tests” (i.e they will call into the actual hardware instead of using mock evidence)

The tests use the environment variables set in test.env.

Unit tests#

The steps to build and run unit tests:

make run-unit-tests # see make help for more info

Integration tests#

make run-integration-tests-gpu
make run-integration-tests-switch

Running examples#

# build and install sdk using make
make run-examples

Coding standards#

  • Class names are camel cased

  • Function names are snake cased

  • Class member variables are prefixed with m_

  • Static global variables are prefixed with g_ (don’t use global variables)

  • All the code is written in nvattestation namespace

  • To implement functions that can return a result or an error, always use a pointer to return the result; nullptr indicates error and use ErrorStack to record the error.

  • Do not use raw pointers, always use smart pointers. If using an external library that returns raw pointers, the first step should to wrap it in a custom smart pointer with a custom deleter. Refer to nv_types.h. Better yet, the custom smart pointer can be directly constructed from the raw pointer.

  • When writing unit tests, if any data needs to be shared between unit tests, use a test fixture from googletest

Release process#

The SDK will be released via package managers for popular Linux distros. Initially only apt will be supported.

It will be versioned as major.minor.patch

There will be 2 packages released: libnvattest{SO_VERSION} and libnvattest-dev. The latter will always point to the latest version of the former, along with development files such as header files and cmake config files.

If version is incremented:

  • Change the version number in the top level CMakeLists. If the major version changes, change the SOVERSION as well.