netdev - Re: [PATCH net-next 2/2] ionic: add devlink firmware update

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: <fb821a31-e4d5-346b-4f5c-6c545661c638@pensando.io>
Date:   Thu, 3 Sep 2020 14:35:34 -0700
From:   Shannon Nelson <snelson@...sando.io>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, kuba@...nel.org,
        moshe@...lanox.com
Subject: Re: [PATCH net-next 2/2] ionic: add devlink firmware update

On 9/3/20 10:30 AM, Jiri Pirko wrote:
> Thu, Sep 03, 2020 at 05:58:42PM CEST, snelson@...sando.io wrote:
>>
>> True, they aren't "needed" for operational purposes, but they are rather
>> useful when inspecting a system after getting a report of bad behavior, and
> I don't think it is nice to pollute dmesg with any arbitrary driver-specific
> messages.
>
>
>> since this should be seldom performed there should be no risk of filling the
>> log.  As far as I can tell, the devlink messages are only seen at the time
>> the flash is performed as output from the flash command, or from a devlink
>> monitor if someone started it before the flash operation.  Is there any other
>> place that can be inspected later that will indicate someone was fussing with
>> the firmware?
> Not really, no. But perhaps we can have a counter for that. Similar to
> what Jakub suggested for reload.
>

When we need to debug a complaint about a firmware load, I want to be 
able to find out what fw file the user actually tried to load, and maybe 
were there other broken load attempts before that.  If there was 
something that broke in the download, it would be nice to know when - 
beginning?  4k bytes in?  near the end?  A counter might show a number 
of load attempts, but no context as to when, what file, or what else was 
going on around the same time.

sln