netdev - RE: [net-next 0/4] devlink: add dry run support for 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: <CO1PR11MB5089A8DC692F9FCB87530639D6B29@CO1PR11MB5089.namprd11.prod.outlook.com>
Date:   Fri, 8 Oct 2021 23:58:45 +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 0/4] devlink: add dry run support for flash update

> -----Original Message-----
> From: Jakub Kicinski <kuba@...nel.org>
> Sent: Friday, October 08, 2021 3:36 PM
> To: Keller, Jacob E <jacob.e.keller@...el.com>
> Cc: Jiri Pirko <jiri@...nulli.us>; netdev@...r.kernel.org
> Subject: Re: [net-next 0/4] devlink: add dry run support for flash update
> 
> On Fri, 8 Oct 2021 21:43:32 +0000 Keller, Jacob E wrote:
> > > > Hmm, old kernel vs. new-userspace, the requested dry-run, won't be
> > > > really dry run. I guess that user might be surprised in that case...
> > >
> > > Would it be enough to do a policy dump in user space to check attr is
> > > recognized and add a warning that this is required next to the attr
> > > in the uAPI header?
> >
> > Doesn't the policy checks prevent any unknown attributes?
> > Or are unknown attributes silently ignored?
> 
> Did you test it?
> 
> DEVLINK_CMD_FLASH_UPDATE has GENL_DONT_VALIDATE_STRICT set.

Hmm. I did run into an issue while initially testing where DEVLINK_ATTR_DRY_RUN wasn't in the devlink_nla_policy table and it rejected the command with an unknown attribute. I had to add the attribute to the policy table to fix this.

I'm double checking on a different kernel now with the new userspace to see if I get the same behavior.

I'm not super familiar with the validation code or what GENL_DONT_VALIDATE_STRICT means...

Indeed.. I just did a search for GENL_DONT_VALIDATE_STRICT and the only uses I can find are ones which *set* the flag. Nothing ever checks it!!

I suspect it got removed at some point.. still digging into exact history though...