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]

Message-ID: <SA2PR11MB5100005E9FEB757A6364C2CFD6959@SA2PR11MB5100.namprd11.prod.outlook.com>
Date:   Mon, 25 Jul 2022 20:27:02 +0000
From:   "Keller, Jacob E" <jacob.e.keller@...el.com>
To:     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: 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