linux-kernel - Re: [PATCH RFC v3 1/6] exterr: 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] [day] [month] [year] [list]

Message-ID: <87d1t89zh5.fsf@ashishki-desk.ger.corp.intel.com>
Date:	Mon, 11 Jan 2016 12:34:14 +0200
From:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Ingo Molnar <mingo@...hat.com>
Cc:	linux-kernel@...r.kernel.org, vince@...ter.net, eranian@...gle.com,
	johannes@...solutions.net,
	Arnaldo Carvalho de Melo <acme@...radead.org>
Subject: Re: [PATCH RFC v3 1/6] exterr: Introduce extended syscall error reporting

Alexander Shishkin <alexander.shishkin@...ux.intel.com> writes:

> It has been pointed out several times that certain system calls' error
> reporting leaves a lot to be desired [1], [2]. Such system calls would
> take complex parameter structures as their input and return -EINVAL if
> one or more parameters are invalid or in conflict leaving it up to the
> user to figure out exactly what is wrong with their request. One such
> syscall is perf_event_open() with its attribute structure containing
> 40+ parameters and tens of parameter validation checks.
>
> This patch introduces a fairly simple infrastructure that allows call
> sites to annotate their error codes with arbitrary strings, which the
> userspace can fetch using a prctl() along with the module name that
> produced the error message, file name, line number and optionally any
> amount of additional information in JSON format. This way, we can
> provide both human-readable and machine-parsable information to user and
> leave room for domain-specific extensions, such as the field in the
> parameter structure that caused the error.
>
> Each error "site" is referred to by its index, which is folded into an
> integer error value within the range of [-EXT_ERRNO, -MAX_ERRNO], where
> EXT_ERRNO is chosen to be below any known error codes, but still leaving
> enough room to enumerate error sites. This way, all the traditional macros
> will still handle these as error codes and we'd only have to convert them
> to their original values right before returning to userspace. At that
> point we'd also store a pointer to the error descriptor in the task_struct,
> so that a subsequent prctl() call can retrieve it.
>
> [1] http://marc.info/?l=linux-kernel&m=141470811013082
> [2] http://marc.info/?l=linux-kernel&m=144049385530680

Ingo, how do you feel about moving this in the more generalized
direction like this or would you say I should give up and keep it perf
specific? Because there seems to be demand for it in the perf land.

Regards,
--
Alex