offer to help, DCB

offer to help, DCB

[Andy Ritger]

Hi Nouveau developers,

NVIDIA is releasing public documentation on certain aspects of our GPUs,
with the intent to address areas that impact the out-of-the-box usability
of NVIDIA GPUs with Nouveau.  We intend to provide more documentation
over time, and guidance in additional areas as we are able.

As a first step towards that, we've posted a document here:

    ftp://download.nvidia.com/open-gpu-doc/DCB/1/DCB-4.0-Specification.html

that documents the Device Control Block ("DCB") layout in the VBIOS.
The DCB describes board topology and the board's display connectors.

I suspect much of the information in that document is not news for
the Nouveau community, but hopefully it will be helpful to confirm your
understanding or flesh out the implementation of a few unhandled cases.

A few of us who work on NVIDIA's proprietary Linux GPU driver will pay
attention to nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org and try to chime in when
we can.

If there are specific areas of documentation that would most help you, that
feedback would help NVIDIA prioritize our documentation efforts.

If you have specific questions for NVIDIA, you can ask here, or direct
them to: open-gpu-doc-DDmLM1+adcqXj1p+fO2waQ@public.gmane.org  I can't promise we'll be able to answer
everything, but we'll provide best-effort in areas where we are able.

Thanks,
- Andy Ritger

Re: offer to help, DCB

[Maarten Lankhorst]

Hey,

Op 24-09-13 06:44, Andy Ritger schreef:
> Hi Nouveau developers,
>
> NVIDIA is releasing public documentation on certain aspects of our GPUs,
> with the intent to address areas that impact the out-of-the-box usability
> of NVIDIA GPUs with Nouveau.  We intend to provide more documentation
> over time, and guidance in additional areas as we are able.
>
> As a first step towards that, we've posted a document here:
>
>     ftp://download.nvidia.com/open-gpu-doc/DCB/1/DCB-4.0-Specification.html
>
> that documents the Device Control Block ("DCB") layout in the VBIOS.
> The DCB describes board topology and the board's display connectors.
>
> I suspect much of the information in that document is not news for
> the Nouveau community, but hopefully it will be helpful to confirm your
> understanding or flesh out the implementation of a few unhandled cases.
>
> A few of us who work on NVIDIA's proprietary Linux GPU driver will pay
> attention to nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org and try to chime in when
> we can.
>
> If there are specific areas of documentation that would most help you, that
> feedback would help NVIDIA prioritize our documentation efforts.
>
> If you have specific questions for NVIDIA, you can ask here, or direct
> them to: open-gpu-doc-DDmLM1+adcqXj1p+fO2waQ@public.gmane.org  I can't promise we'll be able to answer
> everything, but we'll provide best-effort in areas where we are able.
You rock! :D

Our biggest struggle at the moment is the video clocking and power management, which is highly device specific
and depends on configuration too. A complete video bios documentation would be nice too, I understand that will
take a bit longer than just the dcb. :)

~Maarten

Re: offer to help, DCB

[Ben Skeggs]

On Tue, Sep 24, 2013 at 2:44 PM, Andy Ritger <aritger-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>
> Hi Nouveau developers,
Hey Andy, and all you other NVIDIA guys :)

This was a very pleasant shock over breakfast this morning, and is
very much appreciated!

I look forward to seeing how we can all work together in the future!

Thanks again,
Ben.

>
> NVIDIA is releasing public documentation on certain aspects of our GPUs,
> with the intent to address areas that impact the out-of-the-box usability
> of NVIDIA GPUs with Nouveau.  We intend to provide more documentation
> over time, and guidance in additional areas as we are able.
>
> As a first step towards that, we've posted a document here:
>
>     ftp://download.nvidia.com/open-gpu-doc/DCB/1/DCB-4.0-Specification.html
>
> that documents the Device Control Block ("DCB") layout in the VBIOS.
> The DCB describes board topology and the board's display connectors.
>
> I suspect much of the information in that document is not news for
> the Nouveau community, but hopefully it will be helpful to confirm your
> understanding or flesh out the implementation of a few unhandled cases.
>
> A few of us who work on NVIDIA's proprietary Linux GPU driver will pay
> attention to nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org and try to chime in when
> we can.
>
> If there are specific areas of documentation that would most help you, that
> feedback would help NVIDIA prioritize our documentation efforts.
>
> If you have specific questions for NVIDIA, you can ask here, or direct
> them to: open-gpu-doc-DDmLM1+adcqXj1p+fO2waQ@public.gmane.org  I can't promise we'll be able to answer
> everything, but we'll provide best-effort in areas where we are able.
>
> Thanks,
> - Andy Ritger
>
> _______________________________________________
> Nouveau mailing list
> Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: offer to help, DCB

[Andy Ritger]

On Tue, Sep 24, 2013 at 12:12:02AM -0700, Maarten Lankhorst wrote:
> Hey,
> 
> Op 24-09-13 06:44, Andy Ritger schreef:
> > Hi Nouveau developers,
> >
> > NVIDIA is releasing public documentation on certain aspects of our GPUs,
> > with the intent to address areas that impact the out-of-the-box usability
> > of NVIDIA GPUs with Nouveau.  We intend to provide more documentation
> > over time, and guidance in additional areas as we are able.
> >
> > As a first step towards that, we've posted a document here:
> >
> >     ftp://download.nvidia.com/open-gpu-doc/DCB/1/DCB-4.0-Specification.html
> >
> > that documents the Device Control Block ("DCB") layout in the VBIOS.
> > The DCB describes board topology and the board's display connectors.
> >
> > I suspect much of the information in that document is not news for
> > the Nouveau community, but hopefully it will be helpful to confirm your
> > understanding or flesh out the implementation of a few unhandled cases.
> >
> > A few of us who work on NVIDIA's proprietary Linux GPU driver will pay
> > attention to nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org and try to chime in when
> > we can.
> >
> > If there are specific areas of documentation that would most help you, that
> > feedback would help NVIDIA prioritize our documentation efforts.
> >
> > If you have specific questions for NVIDIA, you can ask here, or direct
> > them to: open-gpu-doc-DDmLM1+adcqXj1p+fO2waQ@public.gmane.org

Sorry, I got the email address wrong.  The right address is:

gpu-public-documentation-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org

sorry I didn't double check the address before sending the announcement.

> > I can't promise we'll be able to answer
> > everything, but we'll provide best-effort in areas where we are able.
> You rock! :D

:)  Thanks, Maarten.

> Our biggest struggle at the moment is the video clocking and power management, which is highly device specific
> and depends on configuration too.

Those will be two of the more difficult areas for us to address, but
we'll see what can be done.

> A complete video bios documentation would be nice too, I understand that will
> take a bit longer than just the dcb. :)

BIOS-related information should be a bit easier to get through the
pipeline than other things, so we'll focus on that to start.

I'm looking forward to collaborating with you guys,
- Andy

> ~Maarten

Re: offer to help, DCB

[Dave Airlie]

>> >
>> > NVIDIA is releasing public documentation on certain aspects of our GPUs,
>> > with the intent to address areas that impact the out-of-the-box usability
>> > of NVIDIA GPUs with Nouveau.  We intend to provide more documentation
>> > over time, and guidance in additional areas as we are able.
>> >
>> > As a first step towards that, we've posted a document here:
>> >
>> >     ftp://download.nvidia.com/open-gpu-doc/DCB/1/DCB-4.0-Specification.html
>> >
>> > that documents the Device Control Block ("DCB") layout in the VBIOS.
>> > The DCB describes board topology and the board's display connectors.
>> >
>> > I suspect much of the information in that document is not news for
>> > the Nouveau community, but hopefully it will be helpful to confirm your
>> > understanding or flesh out the implementation of a few unhandled cases.
>> >
>> > A few of us who work on NVIDIA's proprietary Linux GPU driver will pay
>> > attention to nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org and try to chime in when
>> > we can.
>> >
>> > If there are specific areas of documentation that would most help you, that
>> > feedback would help NVIDIA prioritize our documentation efforts.
>> >
>> > If you have specific questions for NVIDIA, you can ask here, or direct
>> > them to: open-gpu-doc-DDmLM1+adcqXj1p+fO2waQ@public.gmane.org
>
> Sorry, I got the email address wrong.  The right address is:
>
> gpu-public-documentation-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org
>
> sorry I didn't double check the address before sending the announcement.
>
>> > I can't promise we'll be able to answer
>> > everything, but we'll provide best-effort in areas where we are able.
>> You rock! :D
>
> :)  Thanks, Maarten.
>
>> Our biggest struggle at the moment is the video clocking and power management, which is highly device specific
>> and depends on configuration too.
>
> Those will be two of the more difficult areas for us to address, but
> we'll see what can be done.
>
>> A complete video bios documentation would be nice too, I understand that will
>> take a bit longer than just the dcb. :)

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?

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, along with VM things
like hw with pagefaults etc.

Dave.

Re: offer to help, DCB

[Andy Ritger]

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.

Re: offer to help, DCB

[Dave Airlie]

On Wed, Sep 25, 2013 at 10:34 AM, Andy Ritger <aritger-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 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.

Re: offer to help, DCB

[Marcin Kościelnicki]

> 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
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: offer to help, DCB

[Andy Ritger]

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ścielnicki

Hi 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@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


_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau