On Mon, Apr 22, 2019 at 07:31:51AM -0400, Dennis Dalessandro wrote: > 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. Thanks, I disagree with your position about HW vendors, many such vendors have no clue what they are doing. Luckily enough, Intel is not such vendor. Thanks > > -Denny > > > > > > >
