Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp8436825ybi; Tue, 23 Jul 2019 08:31:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqw3Zx/F9M1NmIkkCV59qi6P2+gONhePMWyxjLbTcOs0+d/ndWvwtsyBJs0OYJEol36WOrIJ X-Received: by 2002:a17:902:be0a:: with SMTP id r10mr76657131pls.51.1563895874937; Tue, 23 Jul 2019 08:31:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563895874; cv=none; d=google.com; s=arc-20160816; b=w+3PfzojZ2tRCqfe2P+EdlBGZw622JLLwUs/b8+I6MPg8qlqVN+6xL5HqN8Ni/fpGz 5tvDLZSCjbMucZcO4nz6AFvkYwSEXcoRK6CCiW/qVW/zjL0PZfylPevGRzg0nT0WO6SB 0iJ3y7kpfgH4vtLKsicLbuqqb+FPhqV+wHNMnLhzqorRG7Z332HQZzlZIbET3IMp2xjT PCXbNtmGsIi/OFcmnGH4g2U/8fbhZU/DdTjSb7f4MqsKy1lQAKA2NeaVEaEzjE1b1j04 +EaSDgkOFbJy/3UcHOV0uvrgmgj2ItF4zd3ewarwVsxNmIEIdNP4S3QqORLNTs8u61GP SJdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=/aO3fc9NNj4IaHY83vdgv7Bw9DBbI+/ocezrAwA+CwA=; b=kgZv/Z2hvgVxStNFTrBjD04evhsbcnhBvMZPkbcHytmksuCPZTp+jTYgu0/PLzVbay Sn6N25YiBpzKA47Bkt4KmLXHOad05TRuBuaDX50hT0uLmLgus1+GdXIIHM9SOWgaLr7r eZMWn0Ax4yHSzR2l8r4GYQuFemJ03leX0LEOumV1CLlYvKEHWssLrHQBWA1IFAppVseQ C3Axz8clNFcdpeLHelPwo17TjqgOKmubgJkwgJjtON//HavoJJUH0Bzg5+qK5CodtVn2 2wsFJlKRMnu8repy/dFOKop/HEVAY3Y44Dy5bPD077t7pCoJSgPqPVI098f2G8v2LLu7 8Oxg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d19si11403655pgl.53.2019.07.23.08.30.58; Tue, 23 Jul 2019 08:31:14 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388777AbfGWJJL (ORCPT + 99 others); Tue, 23 Jul 2019 05:09:11 -0400 Received: from mx2.suse.de ([195.135.220.15]:36958 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729427AbfGWJJK (ORCPT ); Tue, 23 Jul 2019 05:09:10 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 890A3AF79; Tue, 23 Jul 2019 09:09:09 +0000 (UTC) Received: by unicorn.suse.cz (Postfix, from userid 1000) id 3D87CE0E22; Tue, 23 Jul 2019 11:09:08 +0200 (CEST) Date: Tue, 23 Jul 2019 11:09:08 +0200 From: Michal Kubecek To: netdev@vger.kernel.org Cc: Thomas Haller , "David S. Miller" , Johannes Berg , David Ahern , linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next v2 3/3] netlink: add validation of NLA_F_NESTED flag Message-ID: <20190723090908.GA2204@unicorn.suse.cz> References: <6b6ead21c5d8436470b82ab40355f6bd7dbbf14b.1556806084.git.mkubecek@suse.cz> <0fc58a4883f6656208b9250876e53d723919e342.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0fc58a4883f6656208b9250876e53d723919e342.camel@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 23, 2019 at 10:57:54AM +0200, Thomas Haller wrote: > Does this flag and strict validation really provide any value? > Commonly a netlink message is a plain TLV blob, and the meaning > depends entirely on the policy. > > What I mean is that for example > > NLA_PUT_U32 (msg, ATTR_IFINDEX, (uint32_t) ifindex) > NLA_PUT_STRING (msg, ATTR_IFNAME, "net") > > results in a 4 bytes payload that does not encode whether the data is > a number or a string. > > Why is it valuable in this case to encode additional type information > inside the message, when it's commonly not done and also not > necessary? One big advantage of having nested attributes explicitly marked is that it allows parsers not aware of the semantics to recognize nested attributes and parse their inner structure. This is very important e.g. for debugging purposes as without the flag, wireshark can only recurse into nested attributes if it understands the protocol and knows they are nested, otherwise it displays them only as an opaque blob (which is what happens for most netlink based protocols). Another example is mnl_nlmsg_fprintf() function from libmnl which is also a valuable debugging aid but without NLA_F_NESTED flags it cannot show message structure properly. Michal Kubecek