linux-kernel - Re: [RFC PATCH v3 2/2] fpga: set owner of fpga_manager

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2023121927-desolate-choice-a2fe@gregkh>
Date: Tue, 19 Dec 2023 19:11:09 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Marco Pagani <marpagan@...hat.com>
Cc: Moritz Fischer <mdf@...nel.org>, Wu Hao <hao.wu@...el.com>,
	Xu Yilun <yilun.xu@...el.com>, Tom Rix <trix@...hat.com>,
	linux-kernel@...r.kernel.org, linux-fpga@...r.kernel.org
Subject: Re: [RFC PATCH v3 2/2] fpga: set owner of fpga_manager_ops for
 existing low-level modules

On Tue, Dec 19, 2023 at 06:17:20PM +0100, Marco Pagani wrote:
> 
> On 2023-12-19 16:10, Greg Kroah-Hartman wrote:
> > On Tue, Dec 19, 2023 at 03:54:25PM +0100, Marco Pagani wrote:
> >>
> >>
> >> On 2023-12-18 21:33, Greg Kroah-Hartman wrote:
> >>> On Mon, Dec 18, 2023 at 09:28:09PM +0100, Marco Pagani wrote:
> >>>> This patch tentatively set the owner field of fpga_manager_ops to
> >>>> THIS_MODULE for existing fpga manager low-level control modules.
> >>>>
> >>>> Signed-off-by: Marco Pagani <marpagan@...hat.com>
> >>>> ---
> >>>>  drivers/fpga/altera-cvp.c             | 1 +
> >>>>  drivers/fpga/altera-pr-ip-core.c      | 1 +
> >>>>  drivers/fpga/altera-ps-spi.c          | 1 +
> >>>>  drivers/fpga/dfl-fme-mgr.c            | 1 +
> >>>>  drivers/fpga/ice40-spi.c              | 1 +
> >>>>  drivers/fpga/lattice-sysconfig.c      | 1 +
> >>>>  drivers/fpga/machxo2-spi.c            | 1 +
> >>>>  drivers/fpga/microchip-spi.c          | 1 +
> >>>>  drivers/fpga/socfpga-a10.c            | 1 +
> >>>>  drivers/fpga/socfpga.c                | 1 +
> >>>>  drivers/fpga/stratix10-soc.c          | 1 +
> >>>>  drivers/fpga/tests/fpga-mgr-test.c    | 1 +
> >>>>  drivers/fpga/tests/fpga-region-test.c | 1 +
> >>>>  drivers/fpga/ts73xx-fpga.c            | 1 +
> >>>>  drivers/fpga/versal-fpga.c            | 1 +
> >>>>  drivers/fpga/xilinx-spi.c             | 1 +
> >>>>  drivers/fpga/zynq-fpga.c              | 1 +
> >>>>  drivers/fpga/zynqmp-fpga.c            | 1 +
> >>>>  18 files changed, 18 insertions(+)
> >>>>
> >>>> diff --git a/drivers/fpga/altera-cvp.c b/drivers/fpga/altera-cvp.c
> >>>> index 4ffb9da537d8..aeb913547dd8 100644
> >>>> --- a/drivers/fpga/altera-cvp.c
> >>>> +++ b/drivers/fpga/altera-cvp.c
> >>>> @@ -520,6 +520,7 @@ static const struct fpga_manager_ops altera_cvp_ops = {
> >>>>  	.write_init	= altera_cvp_write_init,
> >>>>  	.write		= altera_cvp_write,
> >>>>  	.write_complete	= altera_cvp_write_complete,
> >>>> +	.owner		= THIS_MODULE,
> >>>
> >>> Note, this is not how to do this, force the compiler to set this for you
> >>> automatically, otherwise everyone will always forget to do it.  Look at
> >>> how functions like usb_register_driver() works.
> >>>
> >>> Also, are you _sure_ that you need a module owner in this structure?  I
> >>> still don't know why...
> >>>
> >>
> >> Do you mean moving the module owner field to the manager context and setting
> >> it during registration with a helper macro?
> > 
> > I mean set it during registration with a helper macro.
> > 
> >> Something like:
> >>
> >> struct fpga_manager {
> >> 	...
> >> 	struct module *owner;
> >> };
> >>
> >> #define fpga_mgr_register(parent, ...) \
> >> 	__fpga_mgr_register(parent,..., THIS_MODULE)
> >>
> >> struct fpga_manager *
> >> __fpga_mgr_register(struct device *parent, ..., struct module *owner)
> >> {
> >> 	...
> >> 	mgr->owner = owner;
> >> }
> > 
> > Yes.
> > 
> > But again, is a module owner even needed?  I don't think you all have
> > proven that yet...
> 
> Programming an FPGA involves a potentially lengthy sequence of interactions
> with the reconfiguration engine. The manager conceptually organizes these
> interactions as a sequence of ops. Low-level modules implement these ops/steps
> for a specific device. If we don't protect the low-level module, someone might
> unload it right when we are in the middle of a low-level op programming the
> FPGA. As far as I know, the kernel would crash in that case.

The only way an unload of a module can happen is if a user explicitly
asks for it to be unloaded.  So they get what they ask for, right?

How do you "know" it is active?  And why doesn't the normal
"driver/device" bindings prevent unloading from being a problem?  When
you unload a module, you stop all ops on the driver, and then unregister
it, which causes any future ones to fail.

Or am I missing something here?

thanks,

greg k-h