linux-kernel - RE: [PATCH v17 0/5] FPGA Image Load (previously Security 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]

Date:   Tue, 26 Oct 2021 06:45:54 +0000
From:   "Wu, Hao" <hao.wu@...el.com>
To:     "Weight, Russell H" <russell.h.weight@...el.com>,
        "Xu, Yilun" <yilun.xu@...el.com>
CC:     Tom Rix <trix@...hat.com>, "mdf@...nel.org" <mdf@...nel.org>,
        "linux-fpga@...r.kernel.org" <linux-fpga@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "lgoncalv@...hat.com" <lgoncalv@...hat.com>,
        "Gerlach, Matthew" <matthew.gerlach@...el.com>
Subject: RE: [PATCH v17 0/5] FPGA Image Load (previously Security Manager)

> >>>>>> The FPGA Image Load Framework was designed with the concept of
> >>>>>> transferring data to a device without imposing a purpose on the data.
> >>>>>> The expectation is that the lower-level driver or the device will
> >>>>>> validate the data. Is there something fundamentally wrong with that
> >>>>> I think there is something wrong here. As I said before, persistent
> >>>>> storage updating has different software process from some runtime
> >>>>> updating, so the class driver should be aware of what the HW engine
> >>>>> is doing.
> >>>> So far, there are no self-describing images that cause a
> >>>> change in run-time behavior, and I don't think that will
> >>>> happen for the very reason that the class-driver would
> >>>> need to know about it.
> >>> Again, the class driver needs to know what is happening, at some
> >>> abstraction level, to ensure the system is aligned with the HW state.
> >>>
> >>> If the class driver cannot tell the detail, it has to assume the
> >>> whole FPGA region will be changed, and removal & re-enumeration is
> >>> needed.
> >> So we make it a requirement that the self-describing files
> >> cannot make changes that require the class driver to manage
> >> state.
> > The API should not only define what it won't do, but also define what
> > it will do. But the "image load" just specifies the top half of the
> > process. So I don't think this API would be accepted.
> So what is the path forward. It seems like you are saying
> that the self-describing files do not fit in the fpga-mgr.
> Can we reconsider the FPGA Image Load Framework, which does
> not make any assumptions about the contents of the image
> files?

Why we need such "generic data transfer" interface in FPGA
framework? we need to handle the common need for FPGA
devices only, not all devices, like programming FPGA images.
So far we even don't know, what's the hardware response on
these self-describing files, how we define it as a common need
interface in the framework? If you just want to reuse the
fpga-mgr/framework code for your own purpose, Yes, it seems
saving some code for you, but finally it loses flexibility, as it's
not possible to extend common framework for your own
purpose in the future.
 
Thanks
Hao