NVIDIA Falcon Microprocessor Security

NVIDIA Falcon Microprocessor Security

[Andy Ritger]

Hi, all.

Below is a link to a brief document describing some changes in NVIDIA
Falcon processors ("fuc", in Nouveau-speak, IIUC) that happened in
Maxwell: certain aspects of the chip will only be available to Falcon
firmware images signed by NVIDIA.  So far, the set of restricted things
is pretty small, but I expect this list will slowly grow over future
hardware generations.

    ftp://download.nvidia.com/open-gpu-doc/Falcon-Security/1/Falcon-Security.html

I suspect this will not be the most popular decision, but it is the
direction the hardware is taking.

On a slightly different note, we'd like to work out the best way to
make NVIDIA firmware images separately (from the rest of the driver)
available and officially redistributable for use by Nouveau.  At this
point, it is mostly just a release engineering question, but I don't think
we'll have a lot of influence over the content: the engineers working on
Falcon microcode assume it changes in lock-step with NVIDIA's nvidia.ko,
so there are no backwards compatibility guarantees.  How painful has
the lack of backwards compatibility been for Nouveau thus far?

If NVIDIA just released firmware binaries along side each NVIDIA GPU driver
release, would it be reasonable for Nouveau to pick and choose which
firmware you'd like promoted to, e.g.,

    http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/

?

Anyway, this might be a good topic to discuss at XDC.  It looks I'll
see a lot of you then; I'm looking forward to it!

Thanks,
- Andy

Re: NVIDIA Falcon Microprocessor Security

[Martin Peres]

Hi Andy,

On 26/09/2014 19:19, Andy Ritger wrote:
> Hi, all.
>
> Below is a link to a brief document describing some changes in NVIDIA
> Falcon processors ("fuc", in Nouveau-speak, IIUC)
We actually renamed most of our docs to falcon :)

> that happened in
> Maxwell: certain aspects of the chip will only be available to Falcon
> firmware images signed by NVIDIA.  So far, the set of restricted things
> is pretty small, but I expect this list will slowly grow over future
> hardware generations.
>
>      ftp://download.nvidia.com/open-gpu-doc/Falcon-Security/1/Falcon-Security.html
>
> I suspect this will not be the most popular decision, but it is the
> direction the hardware is taking.

Thank you for the heads-up! We actually wondered yesterday about
what kind of operations were forbidden without a signed falcon.

> On a slightly different note, we'd like to work out the best way to
> make NVIDIA firmware images separately (from the rest of the driver)
> available and officially redistributable for use by Nouveau.  At this
> point, it is mostly just a release engineering question, but I don't think
> we'll have a lot of influence over the content: the engineers working on
> Falcon microcode assume it changes in lock-step with NVIDIA's nvidia.ko,
> so there are no backwards compatibility guarantees.  How painful has
> the lack of backwards compatibility been for Nouveau thus far?
>
> If NVIDIA just released firmware binaries along side each NVIDIA GPU driver
> release, would it be reasonable for Nouveau to pick and choose which
> firmware you'd like promoted to, e.g.,
>
>      http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/
>
> ?
>
> Anyway, this might be a good topic to discuss at XDC.  It looks I'll
> see a lot of you then; I'm looking forward to it!

Yeah, this really seems like a very good discussion to have at XDC. I'll
find a room for us to sit and discuss the problem.

Thanks again and see you soon!
Martin

Re: NVIDIA Falcon Microprocessor Security

[Ben Skeggs]

On Sat, Sep 27, 2014 at 3:19 AM, Andy Ritger <aritger-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>
> Hi, all.
Hey Andy,

>
> Below is a link to a brief document describing some changes in NVIDIA
> Falcon processors ("fuc", in Nouveau-speak, IIUC)
We started trying to use your names where we know them a while back.
I personally think of "fuc" as short-hand for "falcon ucode" now.

> that happened in
> Maxwell: certain aspects of the chip will only be available to Falcon
> firmware images signed by NVIDIA.  So far, the set of restricted things
> is pretty small, but I expect this list will slowly grow over future
> hardware generations.
>
>     ftp://download.nvidia.com/open-gpu-doc/Falcon-Security/1/Falcon-Security.html
>
> I suspect this will not be the most popular decision, but it is the
> direction the hardware is taking.
Indeed, it's a rather inconvenient and frustrating change.  But it's
what we have to deal with now, so moving along :)

>
> On a slightly different note, we'd like to work out the best way to
> make NVIDIA firmware images separately (from the rest of the driver)
> available and officially redistributable for use by Nouveau.  At this
> point, it is mostly just a release engineering question, but I don't think
> we'll have a lot of influence over the content: the engineers working on
> Falcon microcode assume it changes in lock-step with NVIDIA's nvidia.ko,
> so there are no backwards compatibility guarantees.  How painful has
> the lack of backwards compatibility been for Nouveau thus far?
So far the use of your FECS/GPCCS ucode has been treated as a "last
resort" deal, with a strong preference of using our own when we
finally manage to get it working.  We haven't really changed the
process much over time, and it's probably luck that it's kept
"working" to an extent.  The simplest thing that could be done to ease
this and not enforce some kind of API, is to version the firmware
images in some way, and we can support multiple paths if/when we need
to.

One immediate question I have is that given that FECS/GPCCS pretty
much have zero permissions already outside of the NV_PGRAPH range,
what restrictions are in place there that would prevent us from
continuing to use our own ucode on these falcons?

>
> If NVIDIA just released firmware binaries along side each NVIDIA GPU driver
> release, would it be reasonable for Nouveau to pick and choose which
> firmware you'd like promoted to, e.g.,
>
>     http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/
>
> ?
That would be fine.  I'm somewhat concerned about the possibility we
may get "crippled" ucode compared to what you guys are using, has
there been any discussion on this?

>
> Anyway, this might be a good topic to discuss at XDC.  It looks I'll
> see a lot of you then; I'm looking forward to it!
Indeed it will!  Look forward to seeing you there :)

Thanks,
Ben.

>
> Thanks,
> - Andy
>
>
> _______________________________________________
> Nouveau mailing list
> Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: NVIDIA Falcon Microprocessor Security

[Andy Ritger]

On Sat, Sep 27, 2014 at 10:13:43AM +1000, Ben Skeggs wrote:
> On Sat, Sep 27, 2014 at 3:19 AM, Andy Ritger <aritger-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> >
> > Hi, all.
> Hey Andy,
> 
> >
> > Below is a link to a brief document describing some changes in NVIDIA
> > Falcon processors ("fuc", in Nouveau-speak, IIUC)
> We started trying to use your names where we know them a while back.
> I personally think of "fuc" as short-hand for "falcon ucode" now.

Cool.  You guys are better at naming things than we are, but I'm happy
to have a common language.

> > that happened in
> > Maxwell: certain aspects of the chip will only be available to Falcon
> > firmware images signed by NVIDIA.  So far, the set of restricted things
> > is pretty small, but I expect this list will slowly grow over future
> > hardware generations.
> >
> >     ftp://download.nvidia.com/open-gpu-doc/Falcon-Security/1/Falcon-Security.html
> >
> > I suspect this will not be the most popular decision, but it is the
> > direction the hardware is taking.
> Indeed, it's a rather inconvenient and frustrating change.  But it's
> what we have to deal with now, so moving along :)

Thanks for being understanding.  I also expect if there are any holes
in the signed microcode validation scheme, you all will find them.

> > On a slightly different note, we'd like to work out the best way to
> > make NVIDIA firmware images separately (from the rest of the driver)
> > available and officially redistributable for use by Nouveau.  At this
> > point, it is mostly just a release engineering question, but I don't think
> > we'll have a lot of influence over the content: the engineers working on
> > Falcon microcode assume it changes in lock-step with NVIDIA's nvidia.ko,
> > so there are no backwards compatibility guarantees.  How painful has
> > the lack of backwards compatibility been for Nouveau thus far?
> So far the use of your FECS/GPCCS ucode has been treated as a "last
> resort" deal, with a strong preference of using our own when we
> finally manage to get it working.  We haven't really changed the
> process much over time, and it's probably luck that it's kept
> "working" to an extent.  The simplest thing that could be done to ease
> this and not enforce some kind of API, is to version the firmware
> images in some way, and we can support multiple paths if/when we need
> to.

Yes, I'm sure we can work out some sort of version number.  If nothing
else, the firmware binaries have a perforce changelist number associated
with them, but I'll have to check if that is currently stamped in the
binary, or if that is in a data structure we store along side the binary.

> One immediate question I have is that given that FECS/GPCCS pretty
> much have zero permissions already outside of the NV_PGRAPH range,
> what restrictions are in place there that would prevent us from
> continuing to use our own ucode on these falcons?

I'm not aware of any restrictions, off hand, but I'll see what I can find out.

To me, it seems reasonable for Nouveau to continue to use reimplemented
Falcon firmware until something specific comes up that prevents doing so.

> > If NVIDIA just released firmware binaries along side each NVIDIA GPU driver
> > release, would it be reasonable for Nouveau to pick and choose which
> > firmware you'd like promoted to, e.g.,
> >
> >     http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/
> >
> > ?
> That would be fine.  I'm somewhat concerned about the possibility we
> may get "crippled" ucode compared to what you guys are using, has
> there been any discussion on this?

I don't foresee that.  It seems most desirable for NVIDIA to publish
the exact same firmware binaries we are using within the proprietary
driver, so that the published binaries benefit from the testing we do
on the proprietary driver.  I wouldn't see a benefit to "crippling".

Thanks,
- Andy


> > Anyway, this might be a good topic to discuss at XDC.  It looks I'll
> > see a lot of you then; I'm looking forward to it!
> Indeed it will!  Look forward to seeing you there :)
>
> Thanks,
> Ben.
> 
> >
> > Thanks,
> > - Andy
> >
> >
> > _______________________________________________
> > Nouveau mailing list
> > Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> > http://lists.freedesktop.org/mailman/listinfo/nouveau