netdev - Re: [PATCH net-next v2 3/3] octeontx2-af: add support for custom KPU entries

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: <20200922081313.6e7c8e3a@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Tue, 22 Sep 2020 08:13:13 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Stanislaw Kardach <skardach@...vell.com>
Cc:     <davem@...emloft.net>, <sgoutham@...vell.com>,
        <netdev@...r.kernel.org>, <kda@...ihalf.com>
Subject: Re: [PATCH net-next v2 3/3] octeontx2-af: add support for custom
 KPU entries

On Tue, 22 Sep 2020 13:40:15 +0200 Stanislaw Kardach wrote:
> > So the driver loads the firmware contents, interprets them and programs
> > the device appropriately?
> > 
> > Real firmware files are not usually interpreted or parsed by the driver.  
> 
> Correct. I'm using the firmware file as a delivery method for a custom
> configuration. There are several reasons why I chose it:
> 
> 1. The parsing engine (KPU) has to be configured fully at RVU AF device
>    probe, before any networking part of that or other RVU devices is
>    configured. So I think this rules out devlink, ioctl or sysfs.
> 2. The configuration is rather extensive so cramping it into module
>    parameters doesn't seem right.
> 3. Adding it to Device Tree in form of custom nodes makes update process
>    risky to some users (as opposed to switching firmware file on a
>    filesystem).
> 4. The request_firmware API provides a nice abstraction for the blob data
>    source so I thought it might as well be used for fetching data of a
>    known structure. Especially that the full layout is visible in the
>    kernel and users might create those files themselves by hand.
> 
> That said all above might be because I'm unaware of a better interface to
> use in such situation. If there is, I would be obliged if you could point
> me in the right direction.

Sadly I don't think such interface exists today. You'd need to create
one. Parser configuration is something that has been coming up in
recent years but nobody done the work.

We try to push back on workarounds like this one to force people to
create proper abstract interfaces which can be used by multiple vendors.