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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 15 Sep 2015 10:35:56 -0600
From:	Jonathan Corbet <corbet@....net>
To:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Cc:	Johannes Berg <johannes@...solutions.net>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
	vince@...ter.net, eranian@...gle.com,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	linux-api@...r.kernel.org
Subject: Re: [PATCH RFC v3 1/6] exterr: Introduce extended syscall error
 reporting

[Rather belatedly looping in linux-api]

On Tue, 15 Sep 2015 18:24:28 +0300
Alexander Shishkin <alexander.shishkin@...ux.intel.com> wrote:

> Johannes Berg <johannes@...solutions.net> writes:
> 
> > On Tue, 2015-09-15 at 17:15 +0300, Alexander Shishkin wrote:  
> >>   
> >> > It seems to me that current->ext_err_code needs to be cleared on 
> >> > each system call entry (except for your special prctl() of 
> >> > course!).  
> >> 
> >> I'd say, it should be up to the program to decide for how long they 
> >> want to keep the extended error code around.
> >>   
> >
> > I'm not convinced that works - imagine a library wanting to use the
> > prctl(), but the main application isn't doing that. Should the library
> > clear it before every call, to be sure it's not getting stale data?
> > etc.  
> 
> In other words, a syscall that's capable of throwing an extended error
> does clear the current::ext_err_code every time, but not other
> syscalls. Otherwise it will indeed get very confusing.

I think that anything other than the errno "grab it now or lose it"
behavior will prove confusing.  I don't think there is any other way to
know that a given error report corresponds to a specific system call.
Library calls can mess it up.  Kernel changes adding extended reporting to
new system calls can mess it up.  Applications cannot possibly be expected
to know which system calls might change the error-reporting status, they
*have* to assume all of them will.

Or so it seems to me, anyway...

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