netdev - Re: [PATCH RFC net-next 00/19] Devlink health reporting and recovery system

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: <20190104090111.GB21274@nanopsycho.orion>
Date:   Fri, 4 Jan 2019 10:01:11 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Eran Ben Elisha <eranbe@...lanox.com>
Cc:     Jakub Kicinski <jakub.kicinski@...ronome.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jiri Pirko <jiri@...lanox.com>,
        Moshe Shemesh <moshe@...lanox.com>,
        Aya Levin <ayal@...lanox.com>, Tal Alon <talal@...lanox.com>,
        Ariel Almog <ariela@...lanox.com>
Subject: Re: [PATCH RFC net-next 00/19] Devlink health reporting and recovery
 system

Thu, Jan 03, 2019 at 02:31:59PM CET, eranbe@...lanox.com wrote:
>
>
>On 1/3/2019 12:46 AM, Jakub Kicinski wrote:
>> On Tue, 1 Jan 2019 09:58:30 +0000, Eran Ben Elisha wrote:
>>> On 1/1/2019 3:47 AM, Jakub Kicinski wrote:

[...]

>
>> 
>>>> About the marshalling, I'm not sure it belongs in the kernel.  There is
>>>> precedent for adding interpretation of FW blobs in user space (ethtool).
>>>> IMHO it's a more scalable approach, if we want to avoid having 100 kLoC
>>>> drivers.  Amount of code you add to print the simple example from last
>>>> patch is not inspiring confidence.
>>>
>>> The idea was to provide the developer the ability to create "tree-like"
>>> of information, it is needed when you want to describe complex objects.
>>> This caused a longer coding, but I don't think we are even close to the
>>> scale you are talking about.
>>> We can remove the tree flexibility, and move to array format, it will
>>> make the code of storing data by the driver to be shorter, but we will
>>> lose the ability to have it in tree-like format.
>> 
>> To be clear I slightly oppose the marshalling in the first place.  It
>> may be better to just dump the data as is, and have user space know
>> what the interpretation is.
>
>We provides a way to store the data in nested layers. In internal 
>discussions with Jiri, we decided that this is the correct approach.
>However, if one insists, it can fill the buffers with raw binary and 
>label it as such.

Again, the data is generated by driver. Driver knows the objects, it can
assemble a tree of values accordingly. To me it seems wrong to squash
the info into binary, push to userspace where it has to be parsed and
unsquashed back.