Re: [v2,PCI] move ICHx GbE NVM write-protection from e1000e to PCI quirk

Re: [v2,PCI] move ICHx GbE NVM write-protection from e1000e to PCI quirk

[David Miller]

I'm less than thrilled with this patch so I'm not going to apply it.

I mean, what are we going to do, for every single device that has a
NVRAM we're going to add some PCI quirk and some new global foo_*
kernel command line option to turn it off?

That doesn't make any sense at all, sorry.

Re: [v2,PCI] move ICHx GbE NVM write-protection from e1000e to PCI quirk

[Chris Snook]

David Miller wrote:
> I'm less than thrilled with this patch so I'm not going to apply it.
> 
> I mean, what are we going to do, for every single device that has a
> NVRAM we're going to add some PCI quirk and some new global foo_*
> kernel command line option to turn it off?
> 
> That doesn't make any sense at all, sorry.

Could we protect it in a PCI quirk, and optionally unprotect it in the 
driver?

-- Chris

Re: [v2,PCI] move ICHx GbE NVM write-protection from e1000e to PCI quirk

[David Miller]

From: Chris Snook <csnook@redhat.com>
Date: Mon, 17 Nov 2008 14:40:32 -0500

> David Miller wrote:
> > I'm less than thrilled with this patch so I'm not going to apply it.
> > I mean, what are we going to do, for every single device that has a
> > NVRAM we're going to add some PCI quirk and some new global foo_*
> > kernel command line option to turn it off?
> > That doesn't make any sense at all, sorry.
> 
> Could we protect it in a PCI quirk, and optionally unprotect it in the driver?

I think it's an overreaction, frankly.

Doing it purely in the driver should be fine.

Again are we going to add a NVRAM protect quirk for every PCI
device on the planet that has a NVRAM?

It's not appropriate at all.

RE: [v2,PCI] move ICHx GbE NVM write-protection from e1000e to PCI quirk

[Allan, Bruce W]

Well, no, not for every device with an NVRAM; just those LOM parts in the ICH-based family of products that has an unprotected region of NVRAM and a not-so-difficult set of steps necessary to corrupt the NVRAM by taking advantage of that.  By leaving the write-protection in the driver, the NVRAM can still be damaged before the driver loads (as seen with corruptions from ftrace in 2.6.27) or if the driver is never loaded.

Once the NVRAM is write-protected the driver cannot revoke that protection, only a system reset will do that.  The kernel command line option to disable the write protection is so that if/when a user needs to change a value in the NVRAM it can still be done.


>-----Original Message-----
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Monday, November 17, 2008 11:50 AM
>To: csnook@redhat.com
>Cc: Kirsher, Jeffrey T; Allan, Bruce W; netdev@vger.kernel.org
>Subject: Re: [v2,PCI] move ICHx GbE NVM write-protection from e1000e to
>PCI quirk
>
>From: Chris Snook <csnook@redhat.com>
>Date: Mon, 17 Nov 2008 14:40:32 -0500
>
>> David Miller wrote:
>> > I'm less than thrilled with this patch so I'm not going to apply it.
>> > I mean, what are we going to do, for every single device that has a
>> > NVRAM we're going to add some PCI quirk and some new global foo_*
>> > kernel command line option to turn it off?
>> > That doesn't make any sense at all, sorry.
>>
>> Could we protect it in a PCI quirk, and optionally unprotect it in the
>driver?
>
>I think it's an overreaction, frankly.
>
>Doing it purely in the driver should be fine.
>
>Again are we going to add a NVRAM protect quirk for every PCI
>device on the planet that has a NVRAM?
>
>It's not appropriate at all.

RE: [v2,PCI] move ICHx GbE NVM write-protection from e1000e to PCI quirk

[Ben Hutchings]

On Mon, 2008-11-17 at 12:02 -0800, Allan, Bruce W wrote:
[...]
> Once the NVRAM is write-protected the driver cannot revoke that
> protection, only a system reset will do that.  The kernel command line
> option to disable the write protection is so that if/when a user needs
> to change a value in the NVRAM it can still be done.

Although the ICHx write-protection bit is irreversible without a reset,
it works with SPI flash chips and these normally have their own write-
protection bits that can be switched on and off.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: [v2,PCI] move ICHx GbE NVM write-protection from e1000e to PCI quirk

[David Miller]

From: "Allan, Bruce W" <bruce.w.allan@intel.com>
Date: Mon, 17 Nov 2008 12:02:32 -0800

> Well, no, not for every device with an NVRAM; just those LOM parts
> in the ICH-based family of products that has an unprotected region of
> NVRAM and a not-so-difficult set of steps necessary to corrupt the
> NVRAM by taking advantage of that.  By leaving the write-protection in
> the driver, the NVRAM can still be damaged before the driver loads (as
> seen with corruptions from ftrace in 2.6.27) or if the driver is never
> loaded.
>
> Once the NVRAM is write-protected the driver cannot revoke that
> protection, only a system reset will do that.  The kernel command
> line option to disable the write protection is so that if/when a
> user needs to change a value in the NVRAM it can still be done.

It seems to me the ftrace case could have triggered before PCI
even initializes.

Why not, therefore, write a very-early-initcall mini-driver that
does this instead?

RE: [v2,PCI] move ICHx GbE NVM write-protection from e1000e to PCI quirk

[Allan, Bruce W]

Hmmm, I'll look into it.  Thanks.

>-----Original Message-----
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Monday, November 17, 2008 12:21 PM
>To: Allan, Bruce W
>Cc: csnook@redhat.com; Kirsher, Jeffrey T; netdev@vger.kernel.org
>Subject: Re: [v2,PCI] move ICHx GbE NVM write-protection from e1000e to
>PCI quirk
>
>From: "Allan, Bruce W" <bruce.w.allan@intel.com>
>Date: Mon, 17 Nov 2008 12:02:32 -0800
>
>> Well, no, not for every device with an NVRAM; just those LOM parts
>> in the ICH-based family of products that has an unprotected region of
>> NVRAM and a not-so-difficult set of steps necessary to corrupt the
>> NVRAM by taking advantage of that.  By leaving the write-protection in
>> the driver, the NVRAM can still be damaged before the driver loads (as
>> seen with corruptions from ftrace in 2.6.27) or if the driver is never
>> loaded.
>>
>> Once the NVRAM is write-protected the driver cannot revoke that
>> protection, only a system reset will do that.  The kernel command
>> line option to disable the write protection is so that if/when a
>> user needs to change a value in the NVRAM it can still be done.
>
>It seems to me the ftrace case could have triggered before PCI
>even initializes.
>
>Why not, therefore, write a very-early-initcall mini-driver that
>does this instead?