Re: [PATCH for-next v2] IB/hfi1: Add debugfs to control expansion ROM write protect

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Sorry for the delayed response, this got dumped into my spam folder, which frustratingly happens from time to time.

On 4/12/2019 3:53 PM, Leon Romanovsky wrote:
On Fri, Apr 12, 2019 at 12:34:31PM -0400, Dennis Dalessandro wrote:
On 4/12/2019 11:38 AM, Leon Romanovsky wrote:
On Thu, Apr 11, 2019 at 07:07:42AM -0700, Dennis Dalessandro wrote:
From: Josh Collier <josh.d.collier@xxxxxxxxx>

Some kernels now enable CONFIG_IO_STRICT_DEVMEM
which prevents multiple handles to PCI resource0. In order
to continue to support expansion ROM updates while the
driver is loaded, the driver must now provide an interface
to control the expansion ROM write protection.

  From this description, it seems like that CONFIG_IO_STRICT_DEVMEM was
added to prevent this type of access, doesn't it?

Due to the config option using the resource file is no longer an option for
manipulating the EPROM. There are some accesses that we want to be able to
make through the PCI config space which is not affected by the above config
option. However access to that is protected by the HW. So this patch
provides a safe interface to toggle that protection while still preventing
userspace from free range access to memory regions claimed by the driver.

Thanks for the explanation,

There is one knowledge gap which will be very good to understand.

Someone implemented security option, users decided that it is right thing
and enabled it. Why do you think that it is ok to "disable" such
security check in driver code?

Since it was implemented long ago (years) but only just now being adopted by users, where "users" here is really "distros", I'd say it's not that critical of a security option.

As to why it's OK to disable in the driver, generally speaking I would say that's up to the HW vendor. A HW vendor knows their HW and will have made a decision as to if it's safe for their particular HW or not.

Now in this specific case, we are not circumventing, or disabling the security check. All we are doing is allowing a controlled write to a HW register that turns on/off some HW feature. This happens all over the drivers of course.

-Denny










[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux