On Fri, Jun 21, 2019 at 03:34:28PM -0400, Doug Ledford wrote: > On Fri, 2019-06-21 at 15:20 -0300, Jason Gunthorpe wrote: > > On Thu, Jun 20, 2019 at 12:30:17PM -0400, Doug Ledford wrote: > > > For all string attributes for which we don't currently accept the > > > element as input, we only use it as output, set the string length to > > > RDMA_NLDEV_ATTR_EMPTY_STRING which is defined as 1. That way we > > > will > > > only accept a null string for that element. This will prevent > > > someone > > > from writing a new input routine that uses the element without also > > > updating the policy to have a valid value. > > > > > > Also while there, make sure the existing entries that are valid have > > > the > > > correct policy, if not, correct the policy. Remove unnecessary > > > checks > > > for nla_strlcpy() overflow once the policy has been set correctly. > > > > The above commit message paragraph is out of date now. > > > > Otherwise looks OK to me, it would be nice if we could avoid sizing > > the string in the policy, but OK otherwise. > > > > FWIW this is probably how other netlink users in net are making their > > use of strings OK. The policy will reliably trigger the EINVAL if the > > policy length and the buffer length are identical. > > If that's the case, then we can go back to the original patch and drop > all the checking of string copy overruns because I set all of the policy > elements on anything that was a valid input to the input size. Which was fine for things with nice unfrail global values, but the client_name stack var was not like that.. Maybe just give it some global value? Jason
