On Tue, Sep 24, 2013 at 12:43:46PM -0700, Dave Airlie wrote: ...> > Hey Andy, > > this is great news, > > I suppose the question I have is there any known upfront limits on > what you can release or is it going to be a per-request type thing?Hi Dave. I think we're going to have to deal with things on a case-by-case basis. I wouldn't take anything off the table, yet. You all can probably imagine what areas may have IP/security/whatever entanglements, which will be more painful for NVIDIA to sort through. But, for now, just enumerate what information would be most useful. The more specific and targeted the request, the more focused (and hopefully efficient) the internal vetting process can be.> My main request if you give Ben whatever he asks for :-P, but I'm > interested if you guys would be also able to say review things like > the microcode situation and say explaining what might be missing from > the nouveau microcode for context switching etc,For microcode: from NVIDIA's perspective, I think we'd like to move to a model where NVIDIA releases microcode firmware (as binary-only) with a defined ABI, versioning, and reasonable licensing to allow redistribution. We have some release engineering process improvements to make there, since today the firmware is allowed to evolve along side the NVIDIA proprietary driver code, and the two are released in lock-step. But longer-term, I think we'd like to move things to the firmware that either we're not comfortable documenting, or things that are Real Hard to get right, like P-state switching. Does Nouveau reimplement Falcon microcode due to particular deficiencies in NVIDIA's microcode, or because you couldn't get permission in the past to redistribute the firmware extracted from NVIDIA's proprietary driver? If the latter, I think we can get to the point of solving that with more amenable licensing. If the former, I'd like to report the deficiencies from your point of view back to NVIDIA's firmware team, so that we can improve the firmware for Nouveau use. While I know open firmware would be preferred over binary-only firmware images, hopefully we can find a reasonable compromise there.> along with VM things like hw with pagefaults etc.I don't have a great sense for how much internal concern there will be around pagetable-related documentation. My guess is that it might be a little harder than DCB and other BIOS-related docs, but much easier than clock programming. Thanks, - Andy> Dave.
On Wed, Sep 25, 2013 at 10:34 AM, Andy Ritger <aritger at nvidia.com> wrote:> On Tue, Sep 24, 2013 at 12:43:46PM -0700, Dave Airlie wrote: > ... >> >> Hey Andy, >> >> this is great news, >> >> I suppose the question I have is there any known upfront limits on >> what you can release or is it going to be a per-request type thing? > > Hi Dave. > > I think we're going to have to deal with things on a case-by-case basis. > I wouldn't take anything off the table, yet. You all can probably > imagine what areas may have IP/security/whatever entanglements, which > will be more painful for NVIDIA to sort through. But, for now, just > enumerate what information would be most useful. The more specific and > targeted the request, the more focused (and hopefully efficient) the > internal vetting process can be.Cool good to know.> > For microcode: from NVIDIA's perspective, I think we'd like to move to > a model where NVIDIA releases microcode firmware (as binary-only) with a > defined ABI, versioning, and reasonable licensing to allow redistribution. > We have some release engineering process improvements to make there, since > today the firmware is allowed to evolve along side the NVIDIA proprietary > driver code, and the two are released in lock-step. But longer-term, > I think we'd like to move things to the firmware that either we're not > comfortable documenting, or things that are Real Hard to get right, > like P-state switching. > > Does Nouveau reimplement Falcon microcode due to particular deficiencies > in NVIDIA's microcode, or because you couldn't get permission in the past > to redistribute the firmware extracted from NVIDIA's proprietary driver? > If the latter, I think we can get to the point of solving that with more > amenable licensing. If the former, I'd like to report the deficiencies > from your point of view back to NVIDIA's firmware team, so that we can > improve the firmware for Nouveau use.The initial reason for rewriting microcode was that lack of redistribution rights and how distros like RHEL would work out of the box. I don't think the nouveau microcode is doing anything exotic compared to the nvidia stuff, its probably a lot simpler, and I'm sure there would be some resistance to moving to using the closed blobs only, but there it might be good enough for most people if we could do what AMD do and have a fallback open source microcode for the other cases, though I'm just speaking as RHEL maintainer and watching how much time Ben spends RE'ing microcode :-_ Dave.
> Does Nouveau reimplement Falcon microcode due to particular deficiencies > in NVIDIA's microcode, or because you couldn't get permission in the past > to redistribute the firmware extracted from NVIDIA's proprietary driver? > If the latter, I think we can get to the point of solving that with more > amenable licensing. If the former, I'd like to report the deficiencies > from your point of view back to NVIDIA's firmware team, so that we can > improve the firmware for Nouveau use.While I'm personally one of the guys who wouldn't like to see a binary blob in nouveau, no matter the terms, I've read the firmware blobs decompilation and I'm quite concerned about possible security implications. The PGRAPH context switch microcode allows user to read/write arbitrary MMIO registers by submitting the firmware methods. The GF100+ video decoding etc. falcon microcodes allow you to just ask for physical instead of virtual addressing, and that includes physical system memory. Why did nVidia include such obviously security-breaking functionality in the firmware images? As I understand it, a user having access to just the FIFO submission interface should only have access to his own VM area, and not have enough power to take over the machine. Is there any security model for nVidia hardware/firmware/kernel driver system? Marcin Ko?cielnicki
On Wed, Sep 25, 2013 at 12:46:12AM -0700, Marcin Ko?cielnicki wrote:> > Does Nouveau reimplement Falcon microcode due to particular deficiencies > > in NVIDIA's microcode, or because you couldn't get permission in the past > > to redistribute the firmware extracted from NVIDIA's proprietary driver? > > If the latter, I think we can get to the point of solving that with more > > amenable licensing. If the former, I'd like to report the deficiencies > > from your point of view back to NVIDIA's firmware team, so that we can > > improve the firmware for Nouveau use. > > While I'm personally one of the guys who wouldn't like to see a binary > blob in nouveau, no matter the terms, I've read the firmware blobs > decompilation and I'm quite concerned about possible security implications. > > The PGRAPH context switch microcode allows user to read/write arbitrary > MMIO registers by submitting the firmware methods. The GF100+ video > decoding etc. falcon microcodes allow you to just ask for physical > instead of virtual addressing, and that includes physical system memory. > Why did nVidia include such obviously security-breaking functionality in > the firmware images? As I understand it, a user having access to just > the FIFO submission interface should only have access to his own VM > area, and not have enough power to take over the machine. Is there any > security model for nVidia hardware/firmware/kernel driver system? > > Marcin Ko?cielnickiHi Marcin. I'm not personally familiar with the current implementation of any of NVIDIA's microcode, but what you describe sounds quite serious. I'm taking this up with the correct groups within NVIDIA. Thank you for raising those concerns. Given that, I need to retract my suggestion of Nouveau using NVIDIA's binary-only microcode, at least until we get to a point where NVIDIA has earned some trust from Nouveau in our microcode implementations. Incidentally, if you have additional security concerns with NVIDIA's proprietary driver, please feel free to report them to NVIDIA through unix-security at nvidia.com. I admit that NVIDIA hasn't always been the most responsible in the past, and we definitely have some architectural work to do in the proprietary driver (e.g., moving kickoffs to kernel-space, less brain dead usage of the MMU, etc), but we are trying to take security more seriously. Thanks, - Andy