netdev - Re: [RFC 0/3] netlink: extended error reporting

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 7 Apr 2017 21:35:50 +0200
From:   Pablo Neira Ayuso <pablo@...filter.org>
To:     David Miller <davem@...emloft.net>
Cc:     johannes@...solutions.net, linux-wireless@...r.kernel.org,
        netdev@...r.kernel.org, jiri@...nulli.us
Subject: Re: [RFC 0/3] netlink: extended error reporting

On Fri, Apr 07, 2017 at 12:20:53PM -0700, David Miller wrote:
[...]
> Let's just discuss the UAPI, since people complain we don't talk
> about that enough :-)  For those playing at home it is three new
> attributes returned in a netlink ACK when the application asks
> for the extended response:
> 
> 	NLMSGERR_ATTR_MSG	string	Extended error string
> 	NLMSGERR_ATTR_OFFS	u32	Byte offset to netlink element causing error
> 	NLMSGERR_ATTR_CODE	u32	Subsystem specific error code
> 	NLMSGERR_ATTR_ATTR	u16	Netlink attribute triggering error or missing

I think it would be good if we get a definition to cap the maximum
string length to something reasonable? This can be added in a follow
up patch BTW. Thus, we get people coming back to us and request larger
strings with a reason why they need more room for this.

In general, my main concern with strings is that they can be used in a
more freely way than these u32 offsets and error codes, and
specifically how inconsistent these string will look like across
different netlink subsystems.

Anyway, as long as this is optional (not every subsystem if forced to
use strings) I'm fine with it :).