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: <CO1PR11MB50898047B9C0FAA520505AFDD6B59@CO1PR11MB5089.namprd11.prod.outlook.com>
Date:   Mon, 11 Oct 2021 23:21:51 +0000
From:   "Keller, Jacob E" <jacob.e.keller@...el.com>
To:     "Keller, Jacob E" <jacob.e.keller@...el.com>,
        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: Keller, Jacob E <jacob.e.keller@...el.com>
> Sent: Monday, October 11, 2021 1:22 AM
> To: Jakub Kicinski <kuba@...nel.org>; Jiri Pirko <jiri@...nulli.us>
> Cc: 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?
> 
> I'd be more in favor of converting either this specific op (or devlink as a whole) to
> strict checking. I think that most of the devlink commands and ops would
> function better if unknown behaviors were rejected rather than ignored.
> 
> If we prefer to avoid that due to historically not being strict, I'm ok with a
> userspace check. It does complicate the userspace a bit more, but I agree that
> especially for dry_run we don't want it accidentally updating when a dry run was
> expected.
> 
> There is some maintenance cost to switching to strict checking but I think it's
> pretty minimal because the strict checking simply prevents the unknown
> attributes from being ignored.
> 
> I'm happy to go either direction if we get consensus on this thread though.
> 
> Thanks,
> Jake

The ice changes in this patch conflict with similar work that I posted on IWL to cleanup some things for devlink reload support, so I'll probably wait to re-submit this until those changes make it through IWL and onto the list proper.

Thanks,
Jake