On 8/2/21 10:49 PM, Greg KH wrote: >> If the request_firmware() implementation is not acceptable, then would >> you agree that an IOCTL implementation is our best option? > There is no difference in the end between using an ioctl, or a sysfs > file, to provide the filename of your firmware, don't get hung up on > that. I meant to suggest that passing file data (not a filename) through an IOCTL might be better for this use case than trying to use request_firmware. We have to, somehow, allow the user to point us to the desired image data (which could be a root-entry-hash, or an FPGA image). We can't really use a fixed filename modified by device version as many of the devices do. > By providing a "filename", you are going around all of the namespace and > other "container" protection that the kernel provides, and allowing > processes to potentially load files that are normally outside of their > scope to the hardware. If you are willing to allow that security > "escape", wonderful, but you better document the heck out of it and > explain why this is allowed for your special hardware and use case. > > As you are expecting this to work "in the cloud", I do not think that > the operators of such hardware are really going to be all that happy to > see this type of interface given these reasons. > > What is wrong with the current fpga firmware api that somehow is lacking > for your special hardware, that other devices do not have to worry > about? The existing framework wants to update the live image in the FPGA, whereas for this device, we are passing signed data to BMC firmware which will store it in FLASH to be loaded on a subsequent boot of the card. The existing framework needs to manage FPGA state, whereas for this device, it is just a transfer of signed data. We also have to handle a total transfer/authentication time of up to 45 minutes, so we are using a kernel worker thread for the update. Perhaps the name, fpga security manager, is wrong? Maybe something like fpga_sec_image_xfer is better? - Russ > thanks, > > greg k-h
