On Fri, Sep 15, 2017 at 10:45 AM, Theo de Raadt <dera...@openbsd.org> wrote:
> > On Sat, Sep 09, 2017 at 04:31:47PM -0700, Philip Guenther wrote:
> > > Currently on amd64, the copyin(9) family of calls will pass through the
> > > return value of uvm_fault() and thus return not just EFAULT but
> possibly
> > > EACCES, ENOMEM, and EIO. Since the return value of those functions is
> > > usually passed through to userspace, that's a Bad Thing IMO and we
> need to
> > > fix them to always return EFAULT when uvm_fault() fails.
> >
> > Personally I prefer to see the real error number in user land. It
> > makes it easier to track down the cause of problems if you know the
> > original errno.
>
> But that would change the errno return values from a vast number of
> system calls. That feels like a huge departure from historical Unix.
>
> For instance, open(2) says:
>
> [EFAULT] path points outside the process's allocated address
> space.
>
> I think copyout should only return EFAULT, like it always did, so that
> the return values remain from such failures remain unchanged.
>
Right. Do we really think it's going to be helpful to update stat(2) and
change this:
[EACCES] Search permission is denied for a component of the
path prefix.
To instead read:
[EACCES] Search permission is denied for a component of the
path prefix, or 'sb' points to memory that is
mapped but not writable.
As as both a user and developer, I think that makes my job debugging harder
as now I'm getting the same errno for two conditions, one of which is 100%
programmer error ("passed an unwritable pointer to stat()") and the other
of which is both data dependent and possibly legit and recoverable from
("search permission denied"). Program error and user error mixed in one
message just makes pointing the finger harder.
If I understand Philip, the occurance of other error numbers are just
> an artifacts of in-kernel implementation choices.
>
uvm_fault()'s return value itself propagates up in other internal kernel
interfaces (vslock(), physio(), ...) and controls whether a fatal userspace
page fault generates SIGSEGV or SIGKILL; the artifact here is amd64
ignoring what all the existing archs do and returning it to the copyin
family, a choice which goes back to r1.1
Philip Guenther
