NVIDIA Graphics Firmware Update Tool for DisplayPort Displays

This appears to be a new public tool, 1.0 release out this month.

I hope NVIDIA also makes a release for Linux, not just Windows.

To enable the latest DisplayPort 1.3 / 1.4 features, your graphics card may require a firmware update. Without the update, systems that are connected to a DisplayPort 1.3 / 1.4 monitor could experience blank screens on boot until the OS loads, or could experience a hang on boot. The NVIDIA Firmware Updater will detect whether the firmware update is needed, and if needed, will give the user the option to update it. […]


CVE-2018-6242: ShofEL2 and Fusée Gelée

Re: https://firmwaresecurity.com/2018/04/24/shofel2-a-tegra-x1-and-nintendo-switch-exploit/



NVidia symbol server for Windows binaries

Microsoft’s debugger stores symbols in sidecar files separate from the executable. They are stored on the Microsoft Symbol Server. For third party symbols, things are not as good. NVidia has improved things for their drivers, though:




AFAIK, Mozilla was the first open source project to setup a symbol server:



NVIDIA to stop 32-bit driver development


By Kathleen Maher December 27, 2017
Bye-bye 32, says Nvidia

In a no frills, no hoopla, in a very un-Nvidia like fashion, the company announced that after Release 390, Nvidia will no longer release drivers for 32-bit operating systems for any GPU architecture. The company is currently shipping WHQL driver version 388.71 which suggests there will be a few more 32-bit drivers before the cutoff. Later driver release versions will not operate, nor install, on 32-bit operating systems. Driver enhancements, driver optimizations, and operating system features in driver versions after Release 390 will not be incorporated back into Release 390 or earlier versions. This impacts operating systems such as Microsoft Windows 7, Microsoft Windows 8/8.1, Microsoft Windows 10, Linux, and FreeBSD—applicable to operating systems running on x64 and x32 CPU architectures.

Hmm, I can’t find this info on the NVIDIA pr site:


Alex Matrosov joins NVIDIA!!

This is great news for NVIDIA security!!

Also anyone from ARM Ltd must be quite excited to see recent career paths of ex-CHIPSEC Project members. Alex and Yuriy of Eclypsium has an ARM port of CHIPSEC, which they says they they’re going to release (when!?!). Now Alex is joining Nvidia and will also be focusing on ARM. Note to the Linaro team working on the AArch64 port of LUV-live, once CHIPSEC works on ARM, you really need to get this project active again.

I hope the CHIPSEC team, and or (ARM Ltd, Linaro, Eclypsium, or now NVIDIA) helps update the CHIPSEC Project’s release of CPython. Today it is a binary-only release for x86 and x64, in the Github source tree. It’ll need ARM versions of CPython, and hopefully make CPython build for CHIPSEC transparent, or at least sign the blobs. Actually, this points out an upstream problem to Tianocore: CHIPSEC is an example of an ISV with a UEFI app that needs CPython, and has to ship it themselves. Tianocore should consider shipping CPython binaries along with ShellPkgBin binaries.

PS: I also just noticed that their book has a nice (new?) domain name: http://bootkits.io/ (no HTTPS).


MSI-GT7x-VGA-Switch: toggle Intel/Nvidia VGA from UEFI Shell


These programs or batch scripts will let you swtch the VGA from INTEL to NVIDIA (or the opposite). This is possible at the moment only from Windows (bad choice MSI!). Now it will also be possible from Linux or directly from an EFI SHELL! Intel.nsh and nvidia.nsh are two EFI Shell scripts that can be run directly from EFI shell. Just “make intel” and “make nvidia” to compile the 2 C sources. A reboot is needed afterwards because the VGA is switched by BIOS at boot time.[…]


NVIDIA seeks Embedded Firmware Security Lead

We are looking for an engaged individual with an ability to assimilate complex software designs in order to identify security vulnerabilities and advocate for solutions. The applicant should demonstrate ability to use formal methods such as threat models and attack-trees to support appropriate architectural decisions.You should understand and be able to mentor others in security fundamental and principles of design. This includes testing techniques and a familiarity with static code analysis, dynamic analysis, fuzzing, negative testing and other techniques. Experience with secure code quality practices and tooling to support quick engagements and rapid analysis – static analysis tools (Coverity, Checkmarx, or similar), dynamic scanning (Rapid 7, AppSider, or similar), Fuzzing (AFL, Peach, or similar) and code coverage (Bullseye, LDRA, etc). 


NVIDIA seeks embedded firmware security lead

Embedded Firmware Security Lead
We are now looking for an Embedded Firmware Security Lead. […] Ways to stand out from the crowd:
* Experience with secure code quality practices and tooling to support quick engagements and rapid analysis – static analysis tools (Coverity, Checkmarx, or similar), dynamic scanning (Rapid 7, AppSider, or similar), Fuzzing (AFL, Peach, or similar) and code coverage (Bullseye, LDRA, etc)
* Experience with security incident response activities and penetration testing
* Experience with Ada/Spark language variant and formal proof verification a plus.




GPU security analysis from POSTECH

Stealing Webpages Rendered on Your Browser by Exploiting GPU Vulnerabilities

Graphics processing units (GPUs) are important components of modern computing devices for not only graphics rendering, but also efficient parallel computations. However, their security problems are ignored despite their importance and popularity. In this paper, we first perform an in-depth security analysis on GPUs to detect security vulnerabilities. We observe that contemporary, widely-used GPUs, both NVIDIA’s and AMD’s, do not initialize newly allocated GPU memory pages which may contain sensitive user data. By exploiting such vulnerabilities, we propose attack methods for revealing a victim program’s data kept in GPU memory both during its execution and right after its termination. We further show the high applicability of the proposed attacks by applying them to the Chromium and Firefox web browsers which use GPUs for accelerating webpage rendering. We detect that both browsers leave rendered webpage textures in GPU memory, so that we can infer which webpages a victim user has visited by analyzing the remaining textures. The accuracy of our advanced inference attack that uses both pixel sequence matching and RGB histogram matching is up to 95.4%.

Click to access StealingWebpagesRenderedonYourBrowserbyExploitingGPUVulnerabilities.pdf

NVIDIA signed firmware for Linux





NVIDIA Nouveau Secure Boot

Quoting Michael of Phoronix:

NVIDIA Publishes Nouveau Patches For Secure Boot, Unified Firmware Loading

NVIDIA has released new patches today for helping the open-source Nouveau driver step towards properly supporting the GeForce GTX 900 “Maxwell” graphics cards as well as better supporting Tegra. The first patch series sent out today was authored by NVIDIA’s Alexandre Courbot and provides unified firmware loading functions. He explained, “This patchset centralizes the firmware-loading procedure to one set of functions instead of having each engine load its firmware as it pleases. This helps ensure that all firmware comes from the same place, namely nvidia/chip/. This changes where the firmware is fetched from for falcon/xtensa/bios, but these locations never seemed to have been official anyway. Also for most (all?) chips supported by Nouveau there is corresponding internal firmware, so disruption should be minimal/non-existent. If this assumption is wrong, feel free to drop patches 3-5. At the very least, firmware officially provided by NVIDIA should be looked up using the new functions for consistency.”[…]





coreboot and Chrome OS upstreaming

I mainly work with UEFI technology, and don’t know much about coreboot, nor Chrome OS. I’m new to these tech, and learning them… 🙂

For a while, I thought coreboot was pretty inactive, but I now realize much of the coreboot activity has been taking place in Chrome OS. It appears that some of this work is now being upstreamed to the main coreboot.

From the coreboot blog:

“In the last months there was lots of activity in the coreboot repository due to upstreaming the work that was done in Chrome OS’ branch. We’re happy to announce that both code bases are again relatively close to each other. In the last 7 months, about 1500 commits that landed in coreboot originated in Chrome OS’ repository (of about 2600 total). Those came from 20 domains, which represent pretty much every part of the coreboot community: well known private and commercial coreboot contributors, but also BIOS and silicon developers as well as device manufacturers. Significant contributions that went into the tree recently were written with active support by Broadcom, Imagination Technologies, Intel, Marvell, Nvidia, Qualcomm, and RockChip.”

“In the future, Chrome OS will move over to a new branch point from upstream, and work on strategies to avoid diverging for two long years again. Instead, we’re looking for ways to keep the trees closer while also avoiding flooding the coreboot.org developer base with hundreds of patches. More on that as it is implemented.”

Some features that’ve been recently added include:
* new MIPS support
* improved ARM support, for SoCs by Broadcom, Marvell, Qualcomm, and RockChip
* an improved, safer method to declare the memory map on devices
* effort to get Chrome OS’ verified boot support
* update the flash image format to allow for safer incremental updates

This looks like great news for coreboot! I’ll have more blog entries about coreboot and Chrome OS in the near future.

More Information: