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: <YtwW4aMU96JSXIPw@nanopsycho>
Date:   Sat, 23 Jul 2022 17:42:25 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     "Keller, Jacob E" <jacob.e.keller@...el.com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Jakub Kicinski <kuba@...nel.org>
Subject: Re: [net-next PATCH 1/2] devlink: add dry run attribute to flash
 update

Fri, Jul 22, 2022 at 11:12:27PM CEST, jacob.e.keller@...el.com wrote:
>
>
>> -----Original Message-----
>> From: Jiri Pirko <jiri@...nulli.us>
>> Sent: Thursday, July 21, 2022 11:19 PM
>> To: Keller, Jacob E <jacob.e.keller@...el.com>
>> Cc: netdev@...r.kernel.org; Jakub Kicinski <kuba@...nel.org>
>> Subject: Re: [net-next PATCH 1/2] devlink: add dry run attribute to flash update
>> 
>> Thu, Jul 21, 2022 at 10:32:25PM CEST, jacob.e.keller@...el.com wrote:
>> >
>> >
>> >> -----Original Message-----
>> >> From: Jiri Pirko <jiri@...nulli.us>
>> >> Sent: Wednesday, July 20, 2022 10:55 PM
>> >> To: Keller, Jacob E <jacob.e.keller@...el.com>
>> >> Cc: netdev@...r.kernel.org; Jakub Kicinski <kuba@...nel.org>
>> >> Subject: Re: [net-next PATCH 1/2] devlink: add dry run attribute to flash
>> update
>> >
>> ><...>
>> >
>> >> > struct devlink_region;
>> >> > struct devlink_info_req;
>> >> >diff --git a/include/uapi/linux/devlink.h b/include/uapi/linux/devlink.h
>> >> >index b3d40a5d72ff..e24a5a808a12 100644
>> >> >--- a/include/uapi/linux/devlink.h
>> >> >+++ b/include/uapi/linux/devlink.h
>> >> >@@ -576,6 +576,14 @@ enum devlink_attr {
>> >> > 	DEVLINK_ATTR_LINECARD_TYPE,		/* string */
>> >> > 	DEVLINK_ATTR_LINECARD_SUPPORTED_TYPES,	/* nested */
>> >> >
>> >> >+	/* Before adding this attribute to a command, user space should check
>> >> >+	 * the policy dump and verify the kernel recognizes the attribute.
>> >> >+	 * Otherwise older kernels which do not recognize the attribute may
>> >> >+	 * silently accept the unknown attribute while not actually performing
>> >> >+	 * a dry run.
>> >>
>> >> Why this comment is needed? Isn't that something generic which applies
>> >> to all new attributes what userspace may pass and kernel may ignore?
>> >>
>> >
>> >Because other attributes may not have such a negative and unexpected side
>> effect. In most cases the side effect will be "the thing you wanted doesn't
>> happen", but in this case its "the thing you didn't want to happen does". I think
>> that deserves some warning. A dry run is a request to *not* do something.
>> 
>> Hmm. Another option, in order to be on the safe side, would be to have a
>> new cmd for this...
>> 
>
>I think that the warning and implementation in the iproute2 devlink userspace is sufficient. The alternative would be to work towards converting devlink over to the explicit validation which rejects unknown parameters.. but that has its own backwards compatibility challenges as well.
>
>I guess we could use the same code to implement the command so it wouldn't be too much of a burden to add, but that also means we'd have a pattern of using a new command for every future devlink operation that wants a "dry run". I was anticipating we might want this  kind of option for other commands such as port splitting and unsplitting.
>
>If we were going to add new commands, I would rather we go to the extra trouble of updating all the commands to be strict validation.

I think it is good idea. We would prevent many surprises.

>
>Thanks,
>Jake