netdev - Re: [net-next 0/4] devlink: add dry run support for flash 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]

Date:   Fri, 8 Oct 2021 11:21:59 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     Jacob Keller <jacob.e.keller@...el.com>, netdev@...r.kernel.org
Subject: Re: [net-next 0/4] devlink: add dry run support for flash update

On Fri, 8 Oct 2021 14:37:37 +0200 Jiri Pirko wrote:
> Fri, Oct 08, 2021 at 12:41:11PM CEST, jacob.e.keller@...el.com wrote:
> >This is an implementation of a previous idea I had discussed on the list at
> >https://lore.kernel.org/netdev/51a6e7a33c7d40889c80bf37159f210e@intel.com/
> >
> >The idea is to allow user space to query whether a given destructive devlink
> >command would work without actually performing any actions. This is commonly
> >referred to as a "dry run", and is intended to give tools and system
> >administrators the ability to test things like flash image validity, or
> >whether a given option is valid without having to risk performing the update
> >when not sufficiently ready.
> >
> >The intention is that all "destructive" commands can be updated to support
> >the new DEVLINK_ATTR_DRY_RUN, although this series only implements it for
> >flash update.
> >
> >I expect we would want to support this for commands such as reload as well
> >as other commands which perform some action with no interface to check state
> >before hand.
> >
> >I tried to implement the DRY_RUN checks along with useful extended ACK
> >messages so that even if a driver does not support DRY_RUN, some useful
> >information can be retrieved. (i.e. the stack indicates that flash update is
> >supported and will validate the other attributes first before rejecting the
> >command due to inability to fully validate the run within the driver).  
> 
> Hmm, old kernel vs. new-userspace, the requested dry-run, won't be
> really dry run. I guess that user might be surprised in that case...

Would it be enough to do a policy dump in user space to check attr is
recognized and add a warning that this is required next to the attr
in the uAPI header?