[26.04_linux-nvidia] drtm: Enable ARM64 Secure Launch by ianm-nv · Pull Request #497 · NVIDIA/NV-Kernels

ianm-nv · 2026-07-23T15:19:05Z

BugLink: https://bugs.launchpad.net/bugs/2161563

[Impact]

Enable DRTM (Dynamic Root of Trust for Measurement) on the linux-nvidia kernel,
giving Grace-based platforms hardware-measured boot-integrity attestation. Adds:

ARM64 Secure Launch (DRTM): on drtm=on the kernel (as DLME) requests a
dynamic launch, measures ACPI/DTB/cmdline/initrd into the TPM (PCR 18),
validates the EFI systab/memory map, asserts SMMU DMA protection, and disables
EFI runtime services.
FIRME attestation driver (nvidia_firme): TSM report + measurement-register
backends (configfs/sysfs).

[Test Plan]

On DRTM-capable Grace/GB200 (TF-A/EL3 Secure Launch service + TPM):

Boot drtm=on and confirm the launch engaged: dmesg | grep -i slaunch
shows DRTM Secure Launch detected, the ACPI/DTB/cmdline/initrd measurement
chain, and SMMU DMA protection verified; modprobe nvidia_firme loads.
Boot without drtm=on → boots via the standard EFI stub (feature inert when
not requested).

Validated on Grace/GB200/GB300

[Where problems could occur]

The Secure Launch code is gated behind the drtm=on command-line parameter, so
without it the kernel behaves as before. The one change that applies to every
arm64 build regardless is the kernel image: it ships uncompressed
(EFI_ZBOOT=n), adding about 48 MB to /boot and the package per flavour.

[Other Info]

The trusted-KASLR patches (ARM64_SECURE_LAUNCH_KASLR) are included in the
series but left disabled: enabling them requires MEMORY_HOTPLUG=n. There will
be followup patches to separate this dependency.

References:

Arm DRTM Architecture (DEN0113) — dynamic-launch/DLME interface this
implements: https://developer.arm.com/documentation/den0113/latest/
Arm TRNG Firmware Interface (DEN0098) — SMCCC TRNG_RND64, used by the
trusted-KASLR patches: https://developer.arm.com/documentation/den0098/latest/
Trusted Firmware-A DRTM service — firmware side that performs the launch:
https://trustedfirmware-a.readthedocs.io/en/latest/design_documents/drtm_poc.html
ARM64 Secure Launch upstreaming (LPC 2024, TrenchBoot):
https://lpc.events/event/18/contributions/1814/attachments/1482/3132/arm_securelaunch_lpc_2024.pdf

BugLink: https://bugs.launchpad.net/bugs/2119656 Move region hash initiaization alongside the other region initialization statements to avoid situations where the hash table was not properly initialized. Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Kai-Heng Feng <kaihengf@nvidia.com> Acked-by: Carol L. Soto <csoto@nvidia.com> Acked-by: Koba Ko <kobak@nvidia.com> Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> (cherry picked from commit 8021c1d https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.8-next) Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L. Soto <csoto@nvidia.com> Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> (cherry picked from commit e1264a6 https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.11-next) Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matt Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit 0f8a098 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit 22f790a noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

…rrors BugLink: https://bugs.launchpad.net/bugs/2119656 Update error handling within EGM regiration routine to catch and return errors to the caller. Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Kai-Heng Feng <kaihengf@nvidia.com> Acked-by: Carol L. Soto <csoto@nvidia.com> Acked-by: Koba Ko <kobak@nvidia.com> Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> (cherry picked from commit a57210c https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.8-next) Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L. Soto <csoto@nvidia.com> Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> (cherry picked from commit a706ff8 https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.11-next) Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matt Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit edc0ac0 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit e7a177e noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/2119656 Detect and handle a failure from the EGM registration service. Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Kai-Heng Feng <kaihengf@nvidia.com> Acked-by: Carol L. Soto <csoto@nvidia.com> Acked-by: Koba Ko <kobak@nvidia.com> Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> (cherry picked from commit f18eee3 https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.8-next) Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L. Soto <csoto@nvidia.com> Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> (cherry picked from commit 8371b68 https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.11-next) Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matt Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit be5ae8f noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit 2dd5903 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/2119656 Fix minor syntax errors from sparse. Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Kai-Heng Feng <kaihengf@nvidia.com> Acked-by: Carol L. Soto <csoto@nvidia.com> Acked-by: Koba Ko <kobak@nvidia.com> Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> (cherry picked from commit bbb64e6 https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.8-next) Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L. Soto <csoto@nvidia.com> Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> (cherry picked from commit fe78194 https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.11-next) Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matt Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit b192960 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit c1d3f21 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/2119656 Use the correct macro and types for overflow checking. Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Kai-Heng Feng <kaihengf@nvidia.com> Acked-by: Carol L. Soto <csoto@nvidia.com> Acked-by: Koba Ko <kobak@nvidia.com> Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> (cherry picked from commit afa8f63 https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.8-next) Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L. Soto <csoto@nvidia.com> Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> (cherry picked from commit d110330 https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.11-next) Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matt Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit a6c0508 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit 8ec6da2 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/2119656 Ensure ACPI table reads are successful prior to using the value. Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Kai-Heng Feng <kaihengf@nvidia.com> Acked-by: Carol L. Soto <csoto@nvidia.com> Acked-by: Koba Ko <kobak@nvidia.com> Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> (cherry picked from commit b2947b0 https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.8-next) Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L. Soto <csoto@nvidia.com> Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> (cherry picked from commit 9258355 https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.11-next) Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matt Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit 2c5b472 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit 3f72f24 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/2119656 Some environments may provide a "nvidia,egm-retired-pages-data-base” but fail to populate it with a base address, leaving it NULL. Mapping this invalid value results in a synchronous exception when the region is first touched. Detect a NULL value, generate a warning to draw attention to the firmware bug, and return without mapping. INFO: th500_ras_intr_handler: External Abort reason=1 syndrome=0x92000410 flags=0x1 [ 82.104493] Internal error: synchronous external abort: 0000000096000410 [NVIDIA#1] SMP [ 82.114898] Modules linked in: nvgrace_gpu_vfio_pci(E) nvgrace_egm(E) [ 82.257218] CPU: 0 PID: 10 Comm: kworker/0:1 Tainted: G OE 6.8.12+ NVIDIA#5 [ 82.265135] Hardware name: NVIDIA GH200 P5042, BIOS 24103110 20241031 [ 82.271720] Workqueue: events work_for_cpu_fn [ 82.276180] pstate: 03400009 (nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) [ 82.283298] pc : register_egm_node+0x2cc/0x440 [nvgrace_egm] [ 82.289087] lr : register_egm_node+0x2c4/0x440 [nvgrace_egm] [ 82.294872] sp : ffff8000802ebc30 [ 82.298254] x29: ffff8000802ebc60 x28: 00000000000000ff x27: 0000000000000000 [ 82.305550] x26: ffff000087a320c8 x25: ffff0000a5700000 x24: ffff000087a32000 [ 82.312846] x23: ffffa77cd758e368 x22: 0000000000000000 x21: ffffa77cd758c640 [ 82.320141] x20: ffffa77cd758e170 x19: ffff800081e7d000 x18: ffff800080293038 [ 82.327437] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 82.334732] x14: 0000000000000000 x13: 65203a65646f6e5f x12: 0000000000000000 [ 82.342027] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 [ 82.349322] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 82.356618] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 82.363913] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff800081e7d000 [ 82.371210] Call trace: [ 82.373705] register_egm_node+0x2cc/0x440 [nvgrace_egm] [ 82.379135] nvgrace_gpu_probe+0x2ac/0x528 [nvgrace_gpu_vfio_pci] [ 82.385366] local_pci_probe+0x4c/0xe0 [ 82.389198] work_for_cpu_fn+0x28/0x58 [ 82.393026] process_one_work+0x168/0x3f0 [ 82.397123] worker_thread+0x360/0x480 [ 82.400952] kthread+0x11c/0x128 [ 82.404248] ret_from_fork+0x10/0x20 [ 82.407906] Code: d2820001 940002b3 aa0003f3 b4fffac0 (f9400017) [ 82.414134] ---[ end trace 0000000000000000 ]--- Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Kai-Heng Feng <kaihengf@nvidia.com> Acked-by: Carol L. Soto <csoto@nvidia.com> Acked-by: Koba Ko <kobak@nvidia.com> Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> (cherry picked from commit 7ba2930 https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.8-next) Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L. Soto <csoto@nvidia.com> Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> (cherry picked from commit 349fb1c https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.11-next) Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matt Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit 6e9c94a noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit c5992d5 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/2119656 In an effort to simplify the programming model, use a symmetrical model for the the EGM regsiration APIs. This avoids the caller needing to keep a cookie or even have knowlege of if EGM is supported. Update the EGM unregisration API to use the PCI device as its parameter. Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> (cherry picked from commit d8903ec https://github.com/nvmochs/NV-Kernels/tree/vegm_01232025) Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L. Soto <csoto@nvidia.com> Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> (cherry picked from commit 5839fc5 https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.11-next) Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matt Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit f6fb40e noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit 0e607bc noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

…egions BugLink: https://bugs.launchpad.net/bugs/2119656 GB200 systems could have multiple GPUs associated with an EGM region. For proper EGM functionality the host topology in terms of GPU affinity has to be replicated in the VM. Hence the EGM region structure must track the GPU devices belonging to the same socket. On the device probe, the device pci_dev struct is added to a linked list of the appropriate EGM region. Similarly on device remove, the pci_dev struct for the GPU is removed from the EGM region. Signed-off-by: Ankit Agrawal <ankita@nvidia.com> Ref: sj24: /home/nvidia/ankita/kernel_patches/0001_vfio_nvgrace-egm_track_GPUs_associated_with_the_EGM_regions.patch (koba: Enhance error handling, Remove egm_node from unregister_egm_node and move destroy_egm_chardev a little forward) Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L. Soto <csoto@nvidia.com> Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> (cherry picked from commit 0222c35 https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.11-next) Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matt Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit 5ba1a1f noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit c167095 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/2119656 To replicate the host EGM topology in the VM in terms of the GPU affinity, the userspace need to be aware of which GPUs belong to the same socket as the EGM region. Expose the list of GPUs associated with an EGM region through sysfs. The list can be queried from the location /sys/devices/virtual/egm/egmX/gpu_devices. Signed-off-by: Ankit Agrawal <ankita@nvidia.com> Ref: sj24: /home/nvidia/ankita/kernel_patches/0002_vfio_nvgrace-egm_list_gpus_through_sysfs.patch (koba: Enchance error handling for sysfs_create_group) Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L. Soto <csoto@nvidia.com> Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> (cherry picked from commit fec2356 https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.11-next) Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matt Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit 5dde2f0 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit a5284ca noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/2119656 To allocate the EGM, the userspace need to know it's size. Currently, there is no easy way for the userspace to determine that. Make nvgrace-egm expose the size through sysfs that can be queried by the userspace from /sys/devices/virtual/egm/egmX/egm_size. Signed-off-by: Ankit Agrawal <ankita@nvidia.com> Ref: sj24: /home/nvidia/ankita/kernel_patches/0003_vfio_nvgrace-egm_expose_the_egm_size_through_sysfs.patch Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L. Soto <csoto@nvidia.com> Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> (cherry picked from commit dcdcef2 https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.11-next) Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matt Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit 9940157 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit e025c29 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

…y_failure BugLink: https://bugs.launchpad.net/bugs/2138892 EGM carveout memory is mapped directly into userspace (QEMU) and is not added to the kernel. It is not managed by the kernel page allocator and has no struct pages. The module can thus utilize the Linux memory manager's memory_failure mechanism for regions with no struct pages. The Linux MM code exposes register/unregister APIs allowing modules to register such memory regions for memory_failure handling. Register the EGM PFN range with the MM memory_failure infrastructure on open, and unregister it on the last close. Provide a PFN-to-VMA offset callback that validates the PFN is within the EGM region and the VMA, then converts it to a file offset and records the poisoned offset in the existing hashtable for reporting to userspace. Signed-off-by: Ankit Agrawal <ankita@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Acked-by: Noah Wager <noah.wager@canonical.com> Signed-off-by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit 3fde504 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/2119656 Return the intended errno upon a copyout fault, remove unnecessary checks following container_of pointer derivation, and use the correct macro and types for overflow checking. Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Kai-Heng Feng <kaihengf@nvidia.com> Acked-by: Carol L. Soto <csoto@nvidia.com> Acked-by: Koba Ko <kobak@nvidia.com> Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> (cherry picked from commit 429910b https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.8-next) Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L. Soto <csoto@nvidia.com> Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> (cherry picked from commit bda63f3 https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.11-next) Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matt Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit 942bf3b noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit 63dd059 noble:linux-nvidia-6.17) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>

… allocations BugLink: https://bugs.launchpad.net/bugs/2119656 Add missing null pointer checks after vzalloc() calls in the NVIDIA Grace GPU driver's EGM (External GPU Memory) handling code. This prevents potential null pointer dereferences in the memory failure handling and bad page fetching functions, providing proper error handling for allocation failures. Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L. Soto <csoto@nvidia.com> Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> (cherry picked from commit 63127e2 https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.11-next) Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matt Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit e5f0c8d noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (backported from commit 862ed5a noble:linux-nvidia-6.17) [mochs: Addressed collission for a null pointer check that is no longer needed] Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2142160 When initializing EGM (Extended GPU Memory) regions, the current implementation performs a single memset operation over the entire memory region. For very large regions, this can result in long-running uninterruptible operations that may cause system responsiveness issues or trigger watchdog timeouts. Split the memset operation into 1GB chunks. Signed-off-by: Ankit Agrawal <ankita@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off-by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit 3554744 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/2119656 Add CONFIG_NVGRACE_EGM with policy 'm' for arm64 architecture. Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matt Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit ddf68d0 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit 9ef26d9 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/2028576 The bug indicates NVIDIA wanted to enable the performance governor by default on all arches for the NVIDIA kernels. However, this was mistakenly only configured for arm64 systems. Fix this by also using the performance CPU frequency governor as the default on amd64 systems. Signed-off-by: Jacob Martin <jacob.martin@canonical.com> (cherry picked from commit a530411) (cherry picked from commit a530411 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit 93d3ca3 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/2123861 In nvidia_ffa_create_notifications(), it invokes nvidia_ffa_fill_notification_map(), which fills the virtual notification IDs array supported by the current FFA device. This function updates notification_count after traversing the notification array in the _DSD method. For FFA devices without an entry in the _DSD method, notification_count is assumed to be zero initialized. However, nvidia_ffa_ec_service_probe() uses kmalloc() instead of kzalloc(), so notification_count may contain random values. This causes FFA device probe failures. This patch fixes this by using kzalloc() to zero initialize the nvidia_ec_ffa_device structure. Fixes: ae87187 ("NVIDIA: SAUCE: Add support for notifications from secure EC services") Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Acked-by: Abdur Rahman <abdur.rahman@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit 518a89b noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit bf0587b noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

…PORTLI value BugLink: https://bugs.launchpad.net/bugs/2125126 For DIGITS GB10, USB SuperSpeed Plus Gen2x1 device enumeration speed is being shown as Gen2x2 in the dmesg log. usb 4-1: new SuperSpeed Plus Gen 2x2 USB device number 2 using xhci-hcd The USB3 link lanes count is recorded in the read-only TLC and RLC fields of the PORTLI register. In MT89xx SoCs (used by GB10), the lane count can be wrongly set to 2 instead of 1 for USB Gen2x1 devices due to HW Bug. As per Table 7-13 in USB xHCI revision 1.2 specification, the value 0x5 is for SuperSpeedPlus Gen2x1. This patch adds a SW WAR to read the port speed in PORTSC register. If port speed value is 0x5, then the lane count can be updated to 1. Signed-off-by: Us Chien <us.chien@mediatek.com> Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Kai-Heng Feng <kaihengf@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Acked-by: Abdur Rahman <abdur.rahman@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit b5b3a58 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit c654995 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/2112600 iommu/io-pgtable-arm: Support contiguous bit in translation tables The contiguous bit in translation table entries can be used as a hint to SMMU that a group of adjacent translation table entries have consistent attributes and point to a contiguous and properly aligned output address range. This enables SMMU to predict the properties of the remaining translation table entries in the same group without accessing them. It also allows an SMMU implementation to make more efficient use of its TLB by using a single TLB entry to cover all translation table entries in the same group. In the case of 4KB granule size, there are 16 translation table entries in one group. This change sets the contiguous bit for such groups of entries that are completely covered by a single call to map_pages. As it stands, the code wouldn't set the contiguous bit if a group of adjacent descriptors is completed by separate calls to map_pages. Signed-off-by: Daniel Mentz <danielmentz@google.com> Link: https://lore.kernel.org/linux-iommu/20250430231924.1481493-1-danielmentz@google.com/ [aritger: For the backport: updated the __arm_lpae_init_pte() callsite in arm_lpae_split_blk_unmap() (arm_lpae_split_blk_unmap() is no longer present at top of tree where the original commit was written).] Signed-off-by: Andy Ritger <aritger@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Abdur Rahman <abdur.rahman@canonical.com> Acked-by: Noah Wager <noah.wager@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (backported from commit 990fa55 linux-nvidia-6.11) [kobak: arm_lpae_split_blk_unmap is removed since https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=33729a5fc0caf7a97d20507acbeee6b012e7e519 iommu/io-pgtable-arm: Remove split on unmap behavior so modify as per functions] Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Acked-by: Abdur Rahman <abdur.rahman@canonical.com> Signed-off-by: Ian May <ianm@nvidia.com> (cherry picked from commit c601e60 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/2129209 Add CSA (Channel Switch Announcement) related implementation in collaboration with mac80211 to deal with dynamic channel switching. Signed-off-by: Leon Yen <leon.yen@mediatek.com> Signed-off-by: Ming Yen Hsieh <mingyen.hsieh@mediatek.com> Conflicts: - drivers/net/wireless/mediatek/mt76/mt7925/main.c Code is different in mt7925_add_interface() - drivers/net/wireless/mediatek/mt76/mt792x_core.c Code organization is different Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com> [Backported from https://patchwork.kernel.org/project/linux-wireless/patch/20250926053447.4036650-1-mingyen.hsieh@mediatek.com/] Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Abdur Rahman <abdur.rahman@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off-by: Ian May <ianm@nvidia.com> (cherry picked from commit 060dc92 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

…ype to DMA BugLink: https://bugs.launchpad.net/bugs/2129776 Force DGX Spark systems to use DMA translation as current drivers require this. Suggested-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Abdur Rahman <abdur.rahman@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off-by: Ian May <ianm@nvidia.com> (cherry picked from commit 54575cf noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

…LT_PASSTHROUGH BugLink: https://bugs.launchpad.net/bugs/2129776 Default to CONFIG_IOMMU_DEFAULT_PASSTHROUGH on NVIDIA CPU on kernel above 6.11 as suggested by perf team. x86 always defaults to CONFIG_IOMMU_DEFAULT_DMA_LAZY so remove redundant amd64 setting. Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Abdur Rahman <abdur.rahman@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off-by: Ian May <ianm@nvidia.com> (backported from commit e74a7d8 noble:linux-nvidia-6.17) [mochs: Addressed minor context collission] Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2130445 The call to cat registers2 will acquire rtnl_lock and dump all mapped mmio. Due to acquire rtnl_lock too long, it will cause a kernel panic "not syncing: SBSA Generic Watchdog timeout". Fix this issue by acquiring rtnl_lock every 16 byte when dump all mapped mmio. Signed-off-by: ChunHao Lin <hau@realtek.com> Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Ian May <ian.may@canonical.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Abdur Rahman <abdur.rahman@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit 9737b84 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/2130445 Use following command to do the test. cat /proc/net/r8127/<devname>/test/cdt Signed-off-by: ChunHao Lin <hau@realtek.com> Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Ian May <ian.may@canonical.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Abdur Rahman <abdur.rahman@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit aaf12ca noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

… existing iommu quirk BugLink: https://bugs.launchpad.net/bugs/2132033 Add two more device IDs for the existing Spark iommu quirk. Link: https://bugs.launchpad.net/ubuntu/+source/linux-nvidia-6.14/+bug/2132033 Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Abdur Rahman <abdur.rahman@canonical.com> Acked-by: Noah Wager <noah.wager@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit ba93154 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/2134991 Remove registers2 proc entry as it is causing system crash on running opensource LTP test suite. Change-Id: I47846bca0401d4403fba026d4a348eef3d454f80 Signed-off-by: ChunHao Lin <hau@realtek.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Abdur Rahman <abdur.rahman@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off-by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit 4ff6f9f noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

… DGX Spark BugLink: https://bugs.launchpad.net/bugs/2138269 This driver manages PCIe link for NVIDIA ConnectX-7 (CX7) hot-plug/unplug on DGX Spark systems with GB10 SoC. It disables the PCIe link on cable removal and enables it on cable insertion. Upstream-friendly improvements over 6.14 driver: - Separated from MTK pinctrl driver into NVIDIA platform driver - Configuration via ACPI (_CRS and _DSD), no hardcoded values - Device-managed resources (devm_*) for automatic cleanup - Thread-safe state management with locking - Enhanced error handling and logging - Uses standard Linux kernel APIs The driver exposes a sysfs interface to emulate cable plug in/out: echo 1 > /sys/devices/platform/MTKP0001:00/pcie_hotplug/debug_state # plug in echo 0 > /sys/devices/platform/MTKP0001:00/pcie_hotplug/debug_state # plug out It also provides a runtime enable/disable switch via sysfs: echo 1 > /sys/devices/platform/MTKP0001:00/pcie_hotplug/hotplug_enabled # Enable echo 0 > /sys/devices/platform/MTKP0001:00/pcie_hotplug/hotplug_enabled # Disable This allows enabling/disabling hotplug functionality. Hotplug is disabled by default and must be explicitly enabled via userspace. It also implements uevent notifications for coordination with userspace: * cable plug-in: Report plug-in uevent (driver) Enable PCIe link (driver) Rescan CX7 devices (application) * cable removal: Report removal uevent (driver) Remove CX7 devices (application) Disable PCIe link (driver) Signed-off-by: Vaibhav Vyas <vavyas@nvidia.com> Signed-off-by: Scott Fudally <sfudally@nvidia.com> Signed-off-by: Surabhi Chythanya Kumar <schythanyaku@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off-by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit 4894eb0 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/2059814 Signed-off-by: Brad Figg <bfigg@nvidia.com> Acked-by: Brad Figg <bfigg@nvidia.com> Acked-by: Ian May <ian.may@canonical.com> Signed-off-by: Ian May <ian.may@canonical.com> Signed-off-by: Jacob Martin <jacob.martin@canonical.com> (cherry picked from commit a64b597 linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit 67713ae noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

… control BugLink: https://bugs.launchpad.net/bugs/2138755 The selection of MLO mode should depend on the capabilities of the STA rather than those of the peer AP to avoid compatibility issues with certain APs, such as Xiaomi BE5000 WiFi7 router. Fixes: 69acd6d ("wifi: mt76: mt7925: add mt7925_change_vif_links") Signed-off-by: Leon Yen <leon.yen@mediatek.com> (backported from https://lore.kernel.org/all/20251211123836.4169436-1-leon.yen@mediatek.com/) Signed-off-by: Muteeb Akram <mdoctor@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Acked-by: Abdur Rahman <abdur.rahman@canonical.com> Signed-off-by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit 023106d noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/2161563 DEN0113 defines the DRTM measurement and attestation chain over ACPI: the ACPI tables are measured into the DRTM event log. A launched system that fell back to device tree runs on unmeasured, unvalidated topology with no valid attestation. Panic once acpi_boot_table_init() has finalised acpi_disabled and before the kernel consumes device-tree topology, so a launched system fails closed rather than booting on. Signed-off-by: Raghupathy Krishnamurthy <raghupathyk@nvidia.com> Signed-off-by: Ian May <ianm@nvidia.com>

… style) BugLink: https://bugs.launchpad.net/bugs/2161563 - cast res.a0 to (long) for all DRTM return-code comparisons - rename SL_ROUND_UP_4K -> SL_ROUND_UP_PAGE - log an efi_err when DRTM dynamic launch fails to occur - use dcrtm_type_name() for the address-map region-type print - rename slaunch_assert_full_lockdown -> slaunch_assert_dma_protection Signed-off-by: Raghupathy Krishnamurthy <raghupathyk@nvidia.com> Signed-off-by: Ian May <ianm@nvidia.com>

…andoff BugLink: https://bugs.launchpad.net/bugs/2161563 The Preamble->DLME DTB-PA handoff slot sits at dlme_data_offset - 8. dlme_data_offset was SL_ROUND_UP_PAGE(kernel_memsize), and kernel_memsize is already SEGMENT_ALIGN'd, so the slot fell inside the kernel image tail (early_init_stack/BSS). Push the DLME data region down one page (SL_DLME_DTB_SLOT_GAP) so the slot lands in dedicated scratch below the D-CRTM data. reserve_size grows to match dlme_region_size. Signed-off-by: Raghupathy Krishnamurthy <raghupathyk@nvidia.com> Signed-off-by: Ian May <ianm@nvidia.com>

…ameters BugLink: https://bugs.launchpad.net/bugs/2161563 Make the DRTM code sparse- and warning-clean. Annotate the firmware-ABI structs (drtm_mem_region{,_hdr}, sl_drtm_params) __le* and write them via cpu_to_le*(); annotate the big-endian DTB-header reads __be32; cast const away at the early_memunmap(phdr) unmap. Also remove struct drtm_parameters, which duplicates the live sl_drtm_params and is unused. Signed-off-by: Raghupathy Krishnamurthy <raghupathyk@nvidia.com> Signed-off-by: Ian May <ianm@nvidia.com>

…launch BugLink: https://bugs.launchpad.net/bugs/2161563 A DRTM launch must not call unmeasured pre-DRTM UEFI runtime services. Clearing EFI_RUNTIME_SERVICES in slaunch_setup() is not enough: arm_enable_runtime_services() re-enables it unless disable_runtime is set. Add efi_disable_runtime() (init-only) and call it from slaunch_setup() on a detected launch; drop the stub's efi=noruntime requirement so drtm=on alone requests the launch. Signed-off-by: Raghupathy Krishnamurthy <raghupathyk@nvidia.com> Signed-off-by: Ian May <ianm@nvidia.com>

…MA protection BugLink: https://bugs.launchpad.net/bugs/2161563 slaunch_assert_full_lockdown() was renamed to slaunch_assert_dma_protection(), but "lockdown" and "full-lockdown" still appeared in its comments and panic/info strings, colliding with the kernel lockdown LSM. Rename them to (full-range SMMU) DMA protection for consistency. Signed-off-by: Raghupathy Krishnamurthy <raghupathyk@nvidia.com> Signed-off-by: Ian May <ianm@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2161563 slaunch_exit() has no callers. It performed no DRTM teardown: no SMC, no locality change, no DMA-unprotect; it only zeroed sl_dlme_region_pa. The one-shot launch cleanup already lives in slaunch_setup() (close locality) and the slaunch_unprotect_memory() late_initcall, and DEN0113 defines no DLME "exit" operation. Remove the dead function and both declarations. Signed-off-by: Raghupathy Krishnamurthy <raghupathyk@nvidia.com> Signed-off-by: Ian May <ianm@nvidia.com>

…itBootServices BugLink: https://bugs.launchpad.net/bugs/2161563 The DRTM dynamic launch runs after ExitBootServices, where the EFI console is gone. The old efi_err() on the failure path and the "booting normally" fallback both sat after exit_boot and so could not print. Move both before ExitBootServices: an info breadcrumb ahead of a requested launch (a halt after it means the launch failed), and an error when firmware lacks DRTM support. The breadcrumb is suppressed by "quiet" (and by the default log level on 7.0); the error survives "quiet". The launch SMC's own failure cannot be printed post-EBS without a platform console. Signed-off-by: Raghupathy Krishnamurthy <raghupathyk@nvidia.com> Signed-off-by: Ian May <ianm@nvidia.com>

…fter init BugLink: https://bugs.launchpad.net/bugs/2161563 The EFI stub's writable statics live in the .efistub block placed after _edata (outside the measured image [_text, _edata)), so unlike the stub code in .init.text they are never freed, and their KIMAGE alias stays mapped. Page-align the block, map it as a separately bounded region in the early kernel map (ordinary PTEs at its partial boundary PMDs, no contiguous PTEs), and free + unmap it from free_initmem() like initmem. The reclaim is generic: the .efistub layout exists for all arm64 EFI builds, not only secure launch. Signed-off-by: Raghupathy Krishnamurthy <raghupathyk@nvidia.com> Signed-off-by: Ian May <ianm@nvidia.com>

… requested BugLink: https://bugs.launchpad.net/bugs/2161563 The EFI stub issued the DRTM_FEATURES SMC on every boot to size the DLME data reservation, so a secure-launch-enabled kernel could fault in the stub on platforms without an EL3 monitor. Record the stub's canonical converted command line (a second efi_convert_cmdline() would measure the EFI LoadOptions twice) and gate the probe on the same drtm=on token that gates the launch; grow the reservation only after a successful probe. Unrequested boots issue no SMC and reserve nothing. An explicit drtm=on still requires an EL3 DRTM monitor (noted in the Kconfig help). Signed-off-by: Raghupathy Krishnamurthy <raghupathyk@nvidia.com> Signed-off-by: Ian May <ianm@nvidia.com>

… the image BugLink: https://bugs.launchpad.net/bugs/2161563 When randomization is unavailable or fails, efi_kaslr_relocate_kernel() could execute the image in place while a DRTM boot's reservation extends beyond kernel_memsize (the DTB slot and DLME data tail). That tail lies beyond PE SizeOfImage, and LoadedImage does not expose the backing allocation's extent, so its coverage cannot be assumed (an EFI memory descriptor can also span coalesced neighboring allocations). Take the in-place path only when nothing beyond the image is reserved; otherwise perform a full relocation, which allocates the whole extent. No change when reserve_size == kernel_memsize. Signed-off-by: Raghupathy Krishnamurthy <raghupathyk@nvidia.com> Signed-off-by: Ian May <ianm@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2161563 Under a DRTM Secure Launch the linear/direct map is not randomized (upstream removes it where the CPU PArange < 256 TiB, and the seed would otherwise come from the attacker-visible FDT). Re-randomize memstart_addr over the slack between the linear region and the present-DRAM span, gated by CONFIG_ARM64_SECURE_LAUNCH_KASLR (which gives up memory hotplug). Seed from the PSC-backed firmware TRNG via SMCCC TRNG_RND64 (DEN0098), not CPU RNDR: RNDR is not exposed to NS on all DRTM platforms (NVIDIA Grace reads ID_AA64ISAR0_EL1.RNDR = 0), but EL3 is always present after a Secure Launch. Fail closed if no trusted entropy is available. Signed-off-by: Raghupathy Krishnamurthy <raghupathyk@nvidia.com> Signed-off-by: Ian May <ianm@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2161563 The kernel image KASLR offset is seeded from /chosen/kaslr-seed, which is attacker-visible under a DRTM launch. Prefer the PSC-backed firmware TRNG (SMCCC TRNG_RND64) for the image offset, falling back to the FDT seed. kaslr_early_init() runs in position-independent early code that cannot call arm_smccc_smc() or panic, so issue the SMC via inline asm and gate it on ID_AA64PFR0_EL1.EL3 != 0 (else smc would UNDEF on a no-EL3 boot). The fail-closed enforcement for a missing trusted RNG lives in the linear-map path (arm64_memblock_init). Signed-off-by: Raghupathy Krishnamurthy <raghupathyk@nvidia.com> Signed-off-by: Ian May <ianm@nvidia.com>

…remetal attestation BugLink: https://bugs.launchpad.net/bugs/2161563 Add nvidia-firme kernel module that provides TSM report and TSM measurement register backends for ARM FIRME (DEN0149) Platform Attestation Token retrieval on NVIDIA Grace (TH500) platforms. TSM Reports (configfs): - Invokes FIRME_ATTEST_PAT_GET SMC (0xC4000408) to retrieve platform attestation tokens from PSC via ATF. - Exposes tokens via /sys/kernel/config/tsm/report/ using the standard configfs-tsm UABI (same as ARM CCA, Intel TDX, AMD SEV). TSM Measurement Registers (sysfs): - Invokes FIRME_ATTEST_EXT_CLAIMS SMC (0xC400040B) to extend measurement registers and submit BMDR device reports to PSC. - Slot 0 (bmdr): 100-byte per-GPU device report containing identity_digest (48B), mexchange_digest (48B), gpu_device_id (1B), and reserved (3B). - Slots 1-3 (rem0-rem2): 48-byte SHA-384 extensible measurement slots. - Exposed via /sys/firmware/nvidia-firme/measurements/. Defconfig changes: - Enable CONFIG_ARM64_SECURE_LAUNCH=y for DRTM Secure Launch. - Enable CONFIG_NVIDIA_FIRME_GUEST=m for the attestation driver. - Set CONFIG_CMDLINE="drtm=on efi=noruntime nokaslr" with CONFIG_CMDLINE_EXTEND=y for default DRTM boot parameters. Tested end-to-end on GB300 hardware: DRTM launch, token retrieval (~9KB CCA token with platform + tenant + device tokens), per-GPU BMDR device reports, and REM slot extension. Signed-off-by: Mohamed Sunfeer Hyderali <mhyderali@nvidia.com> Signed-off-by: Ian May <ianm@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2161563 Enable CONFIG_ARM64_SECURE_LAUNCH (selftest/fault-inject knobs off) and disable CONFIG_EFI_ZBOOT, which is incompatible with a measured launch. The remaining '-' entries (EFI_SBAT_FILE, HAVE_KERNEL_GZIP/ZSTD, KERNEL_GZIP/ZSTD) just follow from EFI_ZBOOT=n. Also enable CONFIG_NVIDIA_FIRME_GUEST=m for the FIRME attestation driver. Signed-off-by: Ian May <ianm@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2161563 DRTM Secure Launch needs the non-zboot EFI stub path (CONFIG_EFI_ZBOOT=n), so install the uncompressed, UEFI-signed Image instead of vmlinuz.efi. Signed-off-by: Ian May <ianm@nvidia.com>

github-actions · 2026-07-23T15:30:10Z

PR Validation Report

Patchscan ✅ No Missing Fixes

All cherry-picked commits checked — no missing upstream fixes found.

PR Lint ✅ All checks passed

Details

Checking 39 commits...

Cherry-pick digest:
┌──────────────┬──────────────────────────────────────────────────────────────────┬────────────┬─────────┬───────────────────────────┐
│ Local        │ Referenced upstream / Patch subject                              │ Patch-ID   │ Subject │ SoB chain                 │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 1dab17fda017 │ [SAUCE] [packaging] arm64: install uncompressed image for drtm   │ N/A        │ N/A     │ ianm                      │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 7a9e0f7a01a6 │ [SAUCE] [config] arm64: update annotations for drtm              │ N/A        │ N/A     │ ianm                      │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 34799827483e │ [SAUCE] arm64: add nvidia firme attestation driver for drtm bare │ N/A        │ N/A     │ mhyderal, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 4b9a7ac96bbf │ [SAUCE] arm64: drtm: seed kernel-image kaslr from a trusted rng  │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ ca2f8d5b468c │ [SAUCE] arm64: drtm: randomize the linear map from a trusted rng │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 281d568dd1b2 │ [SAUCE] arm64: drtm: relocate whenever the reservation exceeds t │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 62869e0827f7 │ [SAUCE] arm64: drtm: probe drtm_features only when a launch is r │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 35cf0870ddb7 │ [SAUCE] arm64: drtm: reclaim the efi stub's writable statics aft │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 08765b560f4f │ [SAUCE] arm64: drtm: report the drtm launch decision before exit │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 46d86f297add │ [SAUCE] arm64: drtm: remove unused slaunch_exit()                │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 4eb49d14dc9d │ [SAUCE] arm64: drtm: rename remaining lockdown references to dma │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ a508e6ab1b78 │ [SAUCE] arm64: drtm: force efi runtime services off on a drtm la │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 4620f8f2d9c8 │ [SAUCE] arm64: drtm: annotate endianness, drop unused drtm_param │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ e20d8d385633 │ [SAUCE] arm64: drtm: reserve a dedicated slot for the dtb-pa han │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 44096b351c5d │ [SAUCE] arm64: drtm: address review feedback (naming, logging, s │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ c8995cdc6d20 │ [SAUCE] arm64: drtm: require acpi mode after a secure launch     │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ cc2e6f88d23a │ [SAUCE] arm64: drtm: fail closed if the dlme data header cannot  │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ f7d0d5c63703 │ [SAUCE] arm64: drtm: request secure-interrupt disable across the │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 72b983eb928d │ [SAUCE] arm64: drtm: add overlap fault-injection self-test       │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 04db89f90670 │ [SAUCE] arm64: drtm: refuse acpi device-map of protected ram     │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ b2e541e6ca72 │ [SAUCE] arm64: drtm: kernel-side event log buffer redesign       │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ d4b48bdc1ab1 │ [SAUCE] arm64: drtm: add sha-384 support for production dce firm │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ af54af57f6d1 │ [SAUCE] arm64: drtm: validate untrusted inputs before kernel boo │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 51591437d70b │ [SAUCE] arm64: drtm: validate (not measure) uefi srtm tpm event  │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ f0d552de3cf8 │ [SAUCE] arm64: drtm: measure kernel command line into drtm event │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ fbc0393acd1d │ [SAUCE] arm64: drtm: scrub pe/coff imagebase field pre-drtm laun │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ a24e02364225 │ [SAUCE] arm64: drtm: move efi-stub writable statics past _edata  │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 2513dabbef68 │ [SAUCE] arm64: drtm: allow secure_launch with efi_zboot          │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ cfd5ace98dc4 │ [SAUCE] arm64: drtm: enable secure_launch by default and fix zbo │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 985cd085005c │ [SAUCE] arm64: drtm: add config_arm64_secure_launch kconfig opti │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 61ec9eb8b978 │ [SAUCE] arm64: drtm: self-test, fault-injection harness, slaunch │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 6d6518639046 │ [SAUCE] arm64: drtm: initrd measurement                          │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 16a509b634c3 │ [SAUCE] arm64: drtm: drtm event log extension (dlme-side tcg_pcr │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ e1402f1d79c6 │ [SAUCE] arm64: drtm: acpi table measurement and hash-algo verifi │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 6a1c71916b33 │ [SAUCE] arm64: drtm: raw efi table validation (system table, mma │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 4898b2698a5c │ [SAUCE] arm64: drtm: slaunch_setup, efi runtime disable, full-lo │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ e8831759448c │ [SAUCE] arm64: drtm: address-map validation and dtb validation ( │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 427e66d1098d │ [SAUCE] efi/libstub: arm64: trigger drtm secure launch from efi  │ N/A        │ N/A     │ raghupat, ianm            │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ ddbfbe6cd87a │ [SAUCE] arm64: drtm: add drtm definitions and dlme entry stub    │ N/A        │ N/A     │ raghupat, ianm            │
└──────────────┴──────────────────────────────────────────────────────────────────┴────────────┴─────────┴───────────────────────────┘

Lint: all checks passed.

nirmoy · 2026-07-23T16:38:51Z

BaseOS Kernel Review

Summary

No issues found across the reviewed commits.

Findings: no problems found

Latest watcher review: open review

Generated test plan: open test plan

Kernel deb build: successful (download debs, 4 files)

Head: 1dab17fda017

This comment is maintained by nv-pr-bot. It is updated when the GitHub watcher publishes a newer review.

sforshee · 2026-07-23T16:57:01Z

Codex identified one issue which looks legit in nvidia-firme:

High: drivers/virt/coco/nvidia-firme/nvidia-firme.c:129-179: multi-chunk token retrieval can read/write past the 16 KiB shared buffer. offset is passed to firmware and then used as buf + offset; once offset >= FIRME_BUF_SIZE, the copy is out of bounds. Bound res.a1 to the bounce buffer and copy from the actual chunk base.

There is a check that token_size + res.a1 > FIRME_MAX_TOKEN_SIZE (with offset and token_size having identical values), but FIRME_MAX_TOKEN_SIZE is 32K so this does not prevent overrunning the buffer. I'm honestly not clear on why this code even needs to keep advancing the offset into buf, but I haven't looked at the spec.

A few lower-prioirty, non-blocking observations from me:

A number of pr_info prints in the nvidia-firme driver are probably more pr_debug territory -- i.e. diagnostic messages useful for debugging. Hopefully they don't get printed often, otherwise they may clutter dmesg.
Some functions repeat the same cleanups in multiple error paths; might benefit from a unified cleanup path with goto.

jamieNguyenNVIDIA · 2026-07-23T17:10:53Z

Codex identified one issue which looks legit in nvidia-firme:

High: drivers/virt/coco/nvidia-firme/nvidia-firme.c:129-179: multi-chunk token retrieval can read/write past the 16 KiB shared buffer. offset is passed to firmware and then used as buf + offset; once offset >= FIRME_BUF_SIZE, the copy is out of bounds. Bound res.a1 to the bounce buffer and copy from the actual chunk base.

There is a check that token_size + res.a1 > FIRME_MAX_TOKEN_SIZE (with offset and token_size having identical values), but FIRME_MAX_TOKEN_SIZE is 32K so this does not prevent overrunning the buffer. I'm honestly not clear on why this code even needs to keep advancing the offset into buf, but I haven't looked at the spec.

A few lower-prioirty, non-blocking observations from me:

A number of pr_info prints in the nvidia-firme driver are probably more pr_debug territory -- i.e. diagnostic messages useful for debugging. Hopefully they don't get printed often, otherwise they may clutter dmesg.

Some functions repeat the same cleanups in multiple error paths; might benefit from a unified cleanup path with goto.

Claude flagged the same issue with nvidia-firme.

sforshee · 2026-07-23T17:52:49Z

Codex identified one issue which looks legit in nvidia-firme:

High: drivers/virt/coco/nvidia-firme/nvidia-firme.c:129-179: multi-chunk token retrieval can read/write past the 16 KiB shared buffer. offset is passed to firmware and then used as buf + offset; once offset >= FIRME_BUF_SIZE, the copy is out of bounds. Bound res.a1 to the bounce buffer and copy from the actual chunk base.

There is a check that token_size + res.a1 > FIRME_MAX_TOKEN_SIZE (with offset and token_size having identical values), but FIRME_MAX_TOKEN_SIZE is 32K so this does not prevent overrunning the buffer. I'm honestly not clear on why this code even needs to keep advancing the offset into buf, but I haven't looked at the spec.

A few lower-prioirty, non-blocking observations from me:

A number of pr_info prints in the nvidia-firme driver are probably more pr_debug territory -- i.e. diagnostic messages useful for debugging. Hopefully they don't get printed often, otherwise they may clutter dmesg.

Some functions repeat the same cleanups in multiple error paths; might benefit from a unified cleanup path with goto.

From the spec, FIRME_ATTEST_PAT_GET is a long-running operation using a shared buffer, essentially paginating the data if the supplied buffer isn't large enough for the passed buffer size. When the loop sets challenge_sz to 0 this indicates to subsequent calls that we are continuing the previous incomplete read instead of starting a new one. FIRME_ATTEST_PAT_GET will copy to buf_phys + offset. Since we also pass in a buffer size this may prevent from overwriting the end of the buffer, assuming the firmware is being careful, but then we would still fail to retrieve the full token. From the spec I'm also not entirely sure that the value passed for the buffer size is correct.

I think if the loop is going to copy out the written bytes after each iteration, it should pass 0 as the offset and always copy from the start of the buffer. I've only spent a little time with the spec though, so I may be wrong. But I do think the current code will fail one way or the other if the token size ends up being larger than the allocated buffer size.

jamieNguyenNVIDIA · 2026-07-23T17:58:10Z

Three Claude findings -- 1 and 2 are confirmed from building. 3 is a minor doc inaccuracy. IMO: 1 is the important one to fix.

1. Build break with CONFIG_ARM64_SECURE_LAUNCH=n — c8995cd (high, confirmed by build)

arch/arm64/kernel/setup.c:359 adds:

if (sl_dlme_region_pa && acpi_disabled)
        panic("slaunch: DRTM launch requires ACPI mode, but ACPI is disabled\n");

This reference is not wrapped in any #ifdef, but sl_dlme_region_pa is
declared only under #ifdef CONFIG_ARM64_SECURE_LAUNCH in asm/drtm.h (and its
definition in sl_stub.o is Makefile-gated on the same symbol). Every other
slaunch touch point in setup_arch() resolves to a no-op stub when the feature
is off — only this raw variable is exposed. The config is reachable:
ARM64_SECURE_LAUNCH is a plain bool that depends on ARM64 && EFI, so any
CONFIG_EFI=n build (or an explicit n) fails to compile setup.c. The deb
build here passes only because the shipped config sets it =y.

Confirmed by compiling arch/arm64/kernel/setup.o with ARM64_SECURE_LAUNCH=n:

arch/arm64/kernel/setup.c:359:13: error: ‘sl_dlme_region_pa’ undeclared (first use in this function)
  359 |         if (sl_dlme_region_pa && acpi_disabled)

Fix: use the always-defined helper —

if (slaunch_active() && acpi_disabled)

2. .efistub rename drops the zboot decompressor's initialized .data — a24e023 (medium, confirmed by build)

The change flips STUBCOPY_FLAGS-$(CONFIG_ARM64) from
--prefix-alloc-sections=.init to --prefix-alloc-sections=.efistub and updates
arch/arm64/kernel/vmlinux.lds.S, but not
drivers/firmware/efi/libstub/zboot.lds, which links the same lib.a and still
matches only .init.* / .text* / .data* / .bss*. The old .init prefix
lined up with those globs; the renamed .efistub.* inputs match nothing there
and fall through as orphan sections (the zboot link has no --orphan-handling).

Confirmed on a native arm64 CONFIG_EFI_ZBOOT=y build of the branch. In
arch/arm64/boot/vmlinuz.efi.elf:

[ 8] .data          PROGBITS  ...f23000  size 0x0     (empty)
[ 9] .efistub.data  PROGBITS  ...f23000  size 0x14    (orphan, at _edata)
       -> __efistub_primary_display_guid (16B) + __efistub_efi_loglevel (4B)
_data == _edata == 0xf23000     __data_rawsize = 0

Because __data_rawsize = _edata - _data collapses to 0, the PE .data section
loads zero raw bytes, so the decompressor's initialized statics are zero-filled
at load: efi_loglevel becomes 0 (near-silent decompressor) and
primary_display_guid becomes all-zero. Reverting just the one-line prefix change
restores the correct layout (.efistub.data folds back into .data,
__data_rawsize = 0x200), pinning this commit as the cause. This affects every
arm64 CONFIG_EFI_ZBOOT=y build of the series.

The shipped flavour sets EFI_ZBOOT=n (7a9e0f7), but 2513dab ("Allow
SECURE_LAUNCH with EFI_ZBOOT") re-enables that combination.

Fix: extend the zboot.lds patterns to also match .efistub.* (.text,
.rodata, .data, .bss), or add --orphan-handling=error to the zboot link so
this cannot regress silently.

3. KASLR Kconfig help text names the wrong entropy source — ca2f8d5 (low)

The ARM64_SECURE_LAUNCH_KASLR help text in arch/arm64/Kconfig says the offset
comes from "the CPU's FEAT_RNG (RNDR)" and that it panics "if the CPU lacks
FEAT_RNG (RNDR)," but the code seeds from the SMCCC firmware TRNG
(ARM_SMCCC_TRNG_RND64) and never touches RNDR. Documentation-only; reword to
reference the firmware TRNG.

sforshee

Adding some additional feedback on the nvidia-firme driver after spending more time with DEN0149.

sforshee · 2026-07-23T20:01:00Z

+ * page_count=3 → 16KB buffer, sufficient for most tokens.
+ */
+#define FIRME_BUF_PAGE_COUNT		3
+#define FIRME_MIN_SHARED_BUF_SZ	SZ_4K


Is this a constant because the value is known for the implementations this driver is targeting? Based on DEN0149 v1.0 §8.12, this value should be the minimum size of a shared buffer as per the MIN_SH_BUF_SZ field in FIRME feature register 1. If this is not the same value, the actual size of the buffer may not match the size calculated by the firmware.

sforshee · 2026-07-23T20:07:25Z

+
+		/* Clear challenge after first call */
+		challenge_sz = 0;
+	} while (res.a2 > 0);  /* res.a2 = remaining bytes */


DEN0149 Table 6.1 expressly states that for these return values:

status = INCOMPLETE written size = 0 remaining size = 0

FIRME_ATTEST_PAT_GET must be invoked again to continue retrieving the token. Here the loop terminates. Completion should be based on status == SUCCESS, probably with some retry limits to avoid hanging indefinitely if the firmware is misbehaving.

sforshee · 2026-07-23T20:12:05Z

+
+		memcpy(&token[token_size], buf + offset, res.a1);
+		token_size += res.a1;
+		offset += res.a1;


The psuedocode in DEN0149 has a nested loop, where the inner loop terminates when offset >= buf_size and the outer loop copies the data out of buf and resets offset to zero. As noted previously, here offset could potentially be incremented beyond the end of the buffer. Though I think that is only likely to happen with misbehaving firmware; the more likely outcome is that once offset reaches the buffer size, FIRME_ATTEST_PAT_GET will return INVALID_PARAMETERS. With this implementation copying data out after every FIRME_ATTEST_PAT_GET call the offset should always be 0.

sforshee · 2026-07-23T20:13:59Z

+#define FIRME_MIN_SHARED_BUF_SZ	SZ_4K
+#define FIRME_BUF_SIZE			((FIRME_BUF_PAGE_COUNT + 1) * \
+					 FIRME_MIN_SHARED_BUF_SZ)
+#define FIRME_MAX_TOKEN_SIZE		SZ_32K


What is the basis for this maximum token size? DEN0149 says it should be based on MAX_PAT_PG_CNT from feature register 1.

sforshee · 2026-07-23T20:20:46Z

+		}
+
+		/* res.a1 = bytes written this call, starting at offset in buf */
+		if (token_size + res.a1 > FIRME_MAX_TOKEN_SIZE) {


Though it's highly unlikely, this check is not overflow-safe. I think we can safely assume that res.a1 < FIRME_MAX_TOKEN_SIZE, in which case this would be better:

if (token_size > FIRME_MAX_TOKEN_SIZE - res.a1) { ... }

sforshee · 2026-07-23T20:25:34Z

+{
+	struct arm_smccc_res res;
+
+	arm_smccc_1_1_invoke(FIRME_SERVICE_VERSION, 0, 0, 0, 0, &res);


Should this be checking the attestation service instead of the base service (x1 = 0x4)?

ianm-nv · 2026-07-24T15:44:33Z

Converting to a draft while we sort out the issues identified.

nvmochs and others added 30 commits June 18, 2026 18:19

raghuncstate and others added 16 commits July 23, 2026 13:43

nirmoy added the help wanted Extra attention is needed label Jul 23, 2026

ianm-nv changed the title ~~Enable ARM64 Secure Launch (DRTM)~~ [26.04_linux-nvidia] Enable ARM64 Secure Launch (DRTM) Jul 23, 2026

ianm-nv changed the title ~~[26.04_linux-nvidia] Enable ARM64 Secure Launch (DRTM)~~ [26.04_linux-nvidia] drtm: Enable ARM64 Secure Launch Jul 23, 2026

sforshee reviewed Jul 23, 2026

View reviewed changes

ianm-nv marked this pull request as draft July 24, 2026 15:43

nirmoy removed the help wanted Extra attention is needed label Jul 24, 2026

nvidia-bfigg force-pushed the 26.04_linux-nvidia branch from c2b505a to b472300 Compare July 27, 2026 15:26

Uh oh!

Conversation

ianm-nv commented Jul 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Jul 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Validation Report

Patchscan ✅ No Missing Fixes

PR Lint ✅ All checks passed

Uh oh!

nirmoy commented Jul 23, 2026

BaseOS Kernel Review

Summary

Uh oh!

sforshee commented Jul 23, 2026

Uh oh!

jamieNguyenNVIDIA commented Jul 23, 2026

Uh oh!

sforshee commented Jul 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jamieNguyenNVIDIA commented Jul 23, 2026

Uh oh!

sforshee left a comment

Choose a reason for hiding this comment

Uh oh!

sforshee Jul 23, 2026

Choose a reason for hiding this comment

Uh oh!

sforshee Jul 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sforshee Jul 23, 2026

Choose a reason for hiding this comment

Uh oh!

sforshee Jul 23, 2026

Choose a reason for hiding this comment

Uh oh!

sforshee Jul 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sforshee Jul 23, 2026

Choose a reason for hiding this comment

Uh oh!

ianm-nv commented Jul 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

20 participants

ianm-nv commented Jul 23, 2026 •

edited

Loading

github-actions Bot commented Jul 23, 2026 •

edited

Loading

sforshee commented Jul 23, 2026 •

edited

Loading

sforshee Jul 23, 2026 •

edited

Loading

sforshee Jul 23, 2026 •

edited

Loading