On 9/25/18 11:51 PM, Jiri Benc wrote: > On Tue, 25 Sep 2018 09:37:41 -0600, David Ahern wrote: >> For ifaddrmsg ifa_flags aligns with ifi_type which is set by kernel side >> so this should be ok. > > Does the existing user space set ifi_type to anything? Does it zero out > the field? > > Are we able to find a flag value that is not going to be set by unaware > user space? I.e., a bit that is unused by the current ARPHRD values on > both little and big endian? (ARPHRD_NONE might be a problem, though...)
The goal is for userpsace to pass something to the kernel to definitively state which header is used. ifaddrmsg (proper header and one Christian's patch wants to use) is 8 bytes; ifinfomsg (legacy header from broken userspace) is 16. If you can not trust that ifi_type is currently 0 on a dump request then you can not trust ifi_flags to be correct or ifi_change to be correct and so you can not move past the header and parse attributes. If that is the case we are done - Christian's patches should be reverted as you can never trust what is beyond the family entry. But I do not believe that to be the case because of the route dump analogy. As I mentioned route dumps have the same problem: sometimes ifinfomsg is passed and sometimes rtmsg. Yet the kernel always looks at rtm_flags. In terms of which field to use the most logical to me is to pass in a flag. Current address dumps have no reason to pass in a flag so it is not like the field can be misinterpreted. ifa_flags is a single byte so are there really endian issues to worry about?
