linux-kernel - Re: [PATCH v2 0/6] perf: Introduce extended syscall 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 26 Aug 2015 09:36:29 +0200
From:	Johannes Berg <johannes@...solutions.net>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>, adrian.hunter@...el.com,
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
	Vince Weaver <vince@...ter.net>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Stephane Eranian <eranian@...gle.com>
Subject: Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

On Wed, 2015-08-26 at 09:20 +0200, Ingo Molnar wrote:
> > That's a good point, and think that least in the netlink case it'd be much 
> > better to say which attribute was the one that had an issue, and that has an 
> > obvious binary encoding rather than encoding that in a string.
> 
> So in older discussions about this I suggested a solution for that: also returning 
> (in a channel separate from errnos) the byte offset to the field that caused the 
> error, plus a string - and leaving errnos alone.

I was considering, at least in this case, to forgo the string entirely 
- that makes it use less space in the kernel (no need for all those
strings) and completely avoids the discussion about translation etc.,
while still being entirely sufficient for the debugging I have in mind.

> This only matters for those (few) system calls that have a large attribute space: 
> perf and some of the scheduler syscalls are such.

As I'm saying, netlink is that in a way as well :) Except it's not a
syscall per se, since it's layered behind a message passing interface.

> With this scheme arbitrarily granular error handling can be implemented:
> 
>  - the laziest can just use the errno like usual, which catches 90% of the apps.
> 
>  - the somewhat sophisticated would print the human readable string (or a
>    translation thereof). Would cover another 9%. (This percentage might increase 
>    over time, as the strings become more widely used.)
> 

Well, if the apps were to be extended trivially to print, in the
netlink case, the attribute with an error, that'd help debugging
significantly - not much need for a string in that case.

But I'll agree that it's a more special case than the perf case you're
looking at where you have things like "your hardware doesn't support
this" which obviously isn't really tied to some argument directly.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/