All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russ Weight <russell.h.weight@intel.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Tom Rix <trix@redhat.com>, Moritz Fischer <mdf@kernel.org>,
	<linux-fpga@vger.kernel.org>, <moritzf@google.com>
Subject: Re: [PATCH 02/12] fpga: sec-mgr: enable secure updates
Date: Tue, 3 Aug 2021 12:02:24 -0700	[thread overview]
Message-ID: <3ba35b3c-3c85-394b-f404-130968587a6f@intel.com> (raw)
In-Reply-To: <YQjY+KL59m51kucV@kroah.com>



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


  reply	other threads:[~2021-08-03 19:02 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-17  2:31 [PATCH 00/12] FPGA Security Manager for 5.14 Moritz Fischer
2021-05-17  2:31 ` [PATCH 01/12] fpga: sec-mgr: fpga security manager class driver Moritz Fischer
2021-05-17  5:18   ` Greg KH
2021-05-17 17:45     ` Russ Weight
2021-05-17 17:55       ` Greg KH
2021-05-17 18:25         ` Russ Weight
2021-05-19 20:42           ` Tom Rix
2021-05-21  1:10             ` Russ Weight
2021-05-21  4:58               ` Greg KH
2021-05-21 15:15                 ` Russ Weight
2021-05-17  2:31 ` [PATCH 02/12] fpga: sec-mgr: enable secure updates Moritz Fischer
2021-05-17  5:32   ` Greg KH
2021-05-17 19:37     ` Russ Weight
2021-07-30  1:23       ` Russ Weight
2021-07-30 11:18         ` Greg KH
2021-08-02 18:31           ` Russ Weight
2021-08-03  5:49             ` Greg KH
2021-08-03 19:02               ` Russ Weight [this message]
2021-08-04  7:37                 ` Greg KH
2021-08-04 14:58                   ` Moritz Fischer
2021-08-04 15:12                     ` Greg KH
2021-08-04 19:47                       ` Moritz Fischer
2021-11-02 16:25                       ` Russ Weight
2021-11-02 17:06                         ` Greg KH
2021-05-17  2:31 ` [PATCH 03/12] fpga: sec-mgr: expose sec-mgr update status Moritz Fischer
2021-05-17  2:31 ` [PATCH 04/12] fpga: sec-mgr: expose sec-mgr update errors Moritz Fischer
2021-05-17  2:31 ` [PATCH 05/12] fpga: sec-mgr: expose sec-mgr update size Moritz Fischer
2021-05-17  2:31 ` [PATCH 06/12] fpga: sec-mgr: enable cancel of secure update Moritz Fischer
2021-05-17  2:31 ` [PATCH 07/12] fpga: sec-mgr: expose hardware error info Moritz Fischer
2021-05-17  7:10   ` Greg KH
2021-05-17 19:49     ` Russ Weight
2021-05-17  2:31 ` [PATCH 08/12] fpga: m10bmc-sec: create max10 bmc secure update driver Moritz Fischer
2021-05-17  5:30   ` Greg KH
2021-05-17 20:09     ` Russ Weight
2021-05-17  2:31 ` [PATCH 09/12] fpga: m10bmc-sec: expose max10 flash update count Moritz Fischer
2021-05-17  2:31 ` [PATCH 10/12] fpga: m10bmc-sec: expose max10 canceled keys in sysfs Moritz Fischer
2021-05-17  2:31 ` [PATCH 11/12] fpga: m10bmc-sec: add max10 secure update functions Moritz Fischer
2021-05-17  2:32 ` [PATCH 12/12] fpga: m10bmc-sec: add max10 get_hw_errinfo callback func Moritz Fischer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3ba35b3c-3c85-394b-f404-130968587a6f@intel.com \
    --to=russell.h.weight@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-fpga@vger.kernel.org \
    --cc=mdf@kernel.org \
    --cc=moritzf@google.com \
    --cc=trix@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.