Stefan - I cannot recall who was the nVidia K1 FW lead?  Do you still have the contact to nVidia folks?

Gabe Black and later David Hendricks were firmware leads for Nyan. Both of them have left the team since (and so has Ron Minnich), so I think +Hung-Te and I are the last people left here who worked on it.

As mentioned on email, I'm pretty sure Nyan isn't directly affected by this because it's SoC is not protected with fused keys anyway, so if you can enter USB recovery mode you don't need another exploit to gain control of the system. Whether the board design is safe to prevent entering recovery mode is a different question, I'll try to do some tests.

Ryu should be affected because it tries to protect Android widevine keys even from the physical owners of the device. That is probably broken now (on this device and any other Tegra Android device) because with enough effort you can just open the device and resolder the SoC strappings to force recovery mode. +Furquan was firmware lead for Ryu (and Aaron was also involved who's already on here).

> Setting severity-medium (due to physical access requirement) 

Note that it's theoretically not impossible that a user has a USB device plugged in that can be attacked in some way (e.g. firmware update) which allows a remote attacker to reconfigure it to act as a USB host and perform this exploit. It should be pretty hard and coincidental though (because the attack would likely have to be tailored to one specific device), so probably not a juicy target for just trying to exploit systems en masse.

I think Nyan should be secure as it is. There are three ways to trigger USB recovery mode: through a strapping pin, by failing the normal boot flow, or through a PMC scratch register. The strapping pins are inaccessible without opening the board (and for Nyan, opening the board means the user is allowed to reflash RO firmware anyway). The normal boot flow shouldn't fail (this early) since the descriptor read by the BootROM ("BCT") is in RO flash, so it shouldn't be possible for an attacker to screw with it in a way that would make the BootROM unable to recognize it. The PMC strapping registers are cleared by our normal board reset, including warm resets through the same pin that resets the TPM (the SoC reset-in pin that causes those registers to be cleared is on the same net as the TPM reset pin, so there should be no chance for anything to go wrong there).

Thanks Julius for the detective work! Given that all 3 access vectors are blocked/irrelevant in our threat model, this is indeed a WontFix for nyan.

Regarding Ryu, my understanding is that the Android folks are on top of it - adding Shailesh to cc FYI.

Given all that, I'll close this bug now. If you'd like to track potential Ryu work, please spin off a separate bug specific to that.

Agree with Juilius's statements in #7.

The boot selection is inside our RO flash (assume people didn't re-solder the physical straps) so it won't be tempered unless people have disabled WP.

One thing I'm not 100% sure is if it is possible to program the PMC registers and then try to suspend and resume in developer mode (forgot if we'll reset those).

And no, we didn't program the fuses in Nyan, while we did program fuses on Ryu.

> One thing I'm not 100% sure is if it is possible to program the PMC registers and then try to suspend and resume in developer mode (forgot if we'll reset those).

I don't believe the BootROM can fall into USB recovery on LP0 warmboot (S3 resume in our terminology). But even if it could, that doesn't really give an attacker anything because in order to change PMC scratch registers, he'd already need to have kernel level execution which is all he could gain from this. The resume firmware isn't privileged over the kernel in any way. The TPM doesn't power off in S3 so it will still be locked to the resume firmware.