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:   Tue, 26 Jul 2022 18:21:27 +0000
From:   "Keller, Jacob E" <jacob.e.keller@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>,
        Stephen Hemminger <stephen@...workplumber.org>
CC:     Jiri Pirko <jiri@...nulli.us>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Jonathan Corbet <corbet@....net>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>,
        David Ahern <dsahern@...nel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...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 6:14 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
> 
> Hm, yes. Don't invest too much effort into rendering per-cmd policies
> right now, tho. I've started working on putting the parsing policies
> in YAML last Friday. This way we can auto-gen the policy for the kernel
> and user space can auto-gen the parser/nl TLV writer. Long story short
> we can kill two birds with one stone if you hold off until I have the
> format ironed out. For now maybe just fork the policies into two -
> with and without dry run attr. We'll improve the granularity later
> when doing the YAML conversion.

I'm also worried about the process for transitioning from the existing non-strict policy to a strict validation of per-command policies. How does that impact backwards compatibilty, and will we need to introduce new ops or not?

I know we had to introduce new ops for the strict versions of the PTP ioctls. However those were dealing with (possibly) uninitialized values, where-in userspace may have been accidentally sending values so we could no longer extend the reserved fields.

For netlink, in this case the userspace code would need to be intentionally adding netlink attributes. I would think that well behaved userspace would rather get an error when the command isn't honoring an attribute...

But in a technical sense that would still be breaking backwards compatibility, since it would cause an application that used to "work" to break. Ofcourse in the case of something like DEVLINK_ATTR_DRY_RUN, the userspace may not be working as intended, and it might be considered a bug.

In short: for backwards compatibility, it seems like we might not be able to migrate existing ops to strict validation and would need to replace them? That seems like a very big step...