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:20:20 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Johannes Berg <johannes@...solutions.net>
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


* Johannes Berg <johannes@...solutions.net> wrote:

> On Tue, 2015-08-25 at 22:07 -0700, Linus Torvalds wrote:
> 
> > > No, the current MAX_ERRNO is probably not big enough if this scheme is successful,
> > > and I don't see any reason why it wouldn't be successful: I think this feature
> > > would be the biggest usability feature added to Linux system calls and to Linux
> > > system tooling in the last 10 years or so.
> > Don't be silly. It's a horrible idea. People would want to 
> > internationalize the strings etc, and nobody would use the extended 
> > versions anyway, since nobody uses raw system calls.
> 
> 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.

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

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.)

 - tools with a case of obsessive-compulsive perfectionism would use the structure
   offset to programmatically react to the error condition, and would use the
   human-readable string to explain the precise reason. Would cover another 1% of
   tools.

... but back then I didn't feel like complicating an error recovery ABI for the 
needs of the 1%, robust error handling is all about simplicity: if it's not 
simple, tools won't use it.

Thanks,

	Ingo
--
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/