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]

Message-ID: <CO1PR11MB5089797DA5BA3D7EACE5DE8FD6B29@CO1PR11MB5089.namprd11.prod.outlook.com>
Date:   Fri, 8 Oct 2021 21:43:32 +0000
From:   "Keller, Jacob E" <jacob.e.keller@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>, Jiri Pirko <jiri@...nulli.us>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [net-next 0/4] devlink: add dry run support for flash update



> -----Original Message-----
> From: Jakub Kicinski <kuba@...nel.org>
> Sent: Friday, October 08, 2021 11:22 AM
> To: Jiri Pirko <jiri@...nulli.us>
> Cc: Keller, Jacob E <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.co
> m/
> > >
> > >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?

Doesn't the policy checks prevent any unknown attributes? Or are unknown attributes silently ignored?