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 12:39:17 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     "Keller, Jacob E" <jacob.e.keller@...el.com>
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

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.