From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Ahern Subject: Re: netlink: 16 bytes leftover after parsing attributes in process `ip'. Date: Wed, 26 Sep 2018 08:54:43 -0600 Message-ID: <7ffc4951-0d2e-5bf1-8d64-62ae5d6bc477@gmail.com> References: <6059bf4e-b1cf-2c7e-5529-9003bdd8a14b@gmail.com> <20180925094908.yuu5bsrazkiq3ihy@brauner.io> <20180925164715.338bb059@redhat.com> <02fbfcb8-537c-dc5c-52dc-0f53d7fd0482@gmail.com> <20180926075115.4ca7c527@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Christian Brauner , "netdev@vger.kernel.org" , David Miller To: Jiri Benc Return-path: Received: from mail-pg1-f193.google.com ([209.85.215.193]:39621 "EHLO mail-pg1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726937AbeIZVIG (ORCPT ); Wed, 26 Sep 2018 17:08:06 -0400 Received: by mail-pg1-f193.google.com with SMTP id 85-v6so10990084pge.6 for ; Wed, 26 Sep 2018 07:54:47 -0700 (PDT) In-Reply-To: <20180926075115.4ca7c527@redhat.com> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: 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?