netdev - RE: [net-next PATCH 1/2] devlink: add dry run attribute to 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:   Mon, 25 Jul 2022 20:33:09 +0000
From:   "Keller, Jacob E" <jacob.e.keller@...el.com>
To:     "Keller, Jacob E" <jacob.e.keller@...el.com>,
        Jakub Kicinski <kuba@...nel.org>
CC:     Jiri Pirko <jiri@...nulli.us>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [net-next PATCH 1/2] devlink: add dry run attribute to flash
 update



> -----Original Message-----
> From: Keller, Jacob E <jacob.e.keller@...el.com>
> Sent: Monday, July 25, 2022 1:27 PM
> To: Jakub Kicinski <kuba@...nel.org>
> Cc: Jiri Pirko <jiri@...nulli.us>; netdev@...r.kernel.org
> Subject: RE: [net-next PATCH 1/2] devlink: add dry run attribute to flash update
> 
> 
> 
> > -----Original Message-----
> > From: Jakub Kicinski <kuba@...nel.org>
> > Sent: Monday, July 25, 2022 12:39 PM
> > To: Keller, Jacob E <jacob.e.keller@...el.com>
> > Cc: Jiri Pirko <jiri@...nulli.us>; netdev@...r.kernel.org
> > Subject: Re: [net-next PATCH 1/2] devlink: add dry run attribute to flash update
> >
> > On Mon, 25 Jul 2022 19:15:10 +0000 Keller, Jacob E wrote:
> > > I'm not sure exactly what the process would be here. Maybe something
> > > like:
> > >
> > > 1. identify all of the commands which aren't yet strict
> > > 2. introduce new command IDs for these commands with something like
> > > _STRICT as a suffix? (or something shorter like _2?) 3. make all of
> > > those commands strict validation..
> > >
> > > but now that I think about that, i am not sure it would work. We use
> > > the same attribute list for all devlink commands. This means that
> > > strict validation would only check that its passed existing/known
> > > attributes? But that doesn't necessarily mean the kernel will process
> > > that particular attribute for a given command does it?
> > >
> > > Like, once we introduce DEVLINK_ATTR_DRY_RUN support for flash, if we
> > > then want to introduce it later to something like port splitting.. it
> > > would be a valid attribute to send from kernels which support flash
> > > but would still be ignored on kernels that don't yet support it for
> > > port splitting?
> > >
> > > Wouldn't we want each individual command to have its own validation
> > > of what attributes are valid?
> > >
> > > I do think its probably a good idea to migrate to strict mode, but I
> > > am not sure it solves the problem of dry run. Thoughts? Am I missing
> > > something obvious?
> > >
> > > Would we instead have to convert from genl_small_ops to genl_ops and
> > > introduce a policy for each command? I think that sounds like the
> > > proper approach here....
> >
> > ...or repost without the comment and move on. IDK if Jiri would like
> > to see the general problem of attr rejection solved right now but IMHO
> > it's perfectly fine to just make the user space DTRT.
> 
> Its probably worth fixing policy, but would like to come up with a proper path
> that doesn't break compatibility and that will require discussion to figure out
> what approach works.
> 
> I'll remove the comment though since this problem affects all attributes.
> 
> Thanks,
> Jake

Hmm. The more I think about it, the more it seems that per-command policy is the only way to make the addition of dry_run to new commands safe. Without it, we'd run the risk of a future kernel supporting dry_run but a command not supporting it yet.