netdev - Re: devlink interface for asynchronous event/messages from firmware?

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:   Fri, 22 May 2020 10:46:33 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     Jacob Keller <jacob.e.keller@...el.com>,
        Ido Schimmel <idosch@...sch.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        petrm@...lanox.com, amitc@...lanox.com
Subject: Re: devlink interface for asynchronous event/messages from
 firmware?

On Fri, 22 May 2020 13:00:28 +0200 Jiri Pirko wrote:
> Thu, May 21, 2020 at 11:51:13PM CEST, kuba@...nel.org wrote:
> >On Thu, 21 May 2020 13:59:32 -0700 Jacob Keller wrote:  
> >> >> So the ice firmware can optionally send diagnostic debug messages via
> >> >> its control queue. The current solutions we've used internally
> >> >> essentially hex-dump the binary contents to the kernel log, and then
> >> >> these get scraped and converted into a useful format for human consumption.
> >> >>
> >> >> I'm not 100% of the format, but I know it's based on a decoding file
> >> >> that is specific to a given firmware image, and thus attempting to tie
> >> >> this into the driver is problematic.    
> >> > 
> >> > You explained how it works, but not why it's needed :)    
> >> 
> >> Well, the reason we want it is to be able to read the debug/diagnostics
> >> data in order to debug issues that might be related to firmware or
> >> software mis-use of firmware interfaces.
> >> 
> >> By having it be a separate interface rather than trying to scrape from
> >> the kernel message buffer, it becomes something we can have as a
> >> possibility for debugging in the field.  
> >
> >For pure debug/tracing perhaps trace_devlink_hwerr() is the right fit?  
> 
> Well, trace_devlink_hwerr() is for simple errors that are mapped 1:1
> with some string.

Ah, damn, I missed it takes char :/

> From what I got, Jacob needs to pass some data structures to the
> user. Something more similar to health reporter dumps and their fmsg.

For health reporters AFAIU right now every health reporter event
indicates something bad has happened, so it should be logged and
potentially reported to the vendor.

My understanding is that Jake needs more of a tracing infra, for
debug messages. Is that true? Do you need an on/off switch for 
those as well?