Re: AUDIT: copy_from_user is a deathtrap.

[Marco Colombo]

[Cc: cleared]

On Tue, 21 May 2002, Pavel Machek wrote:

> Hi!
> 
> > > I thought POSIX made it explicit that you may SIGSEGV or EFAULT at your
> > > option. If that SUS rule is stupid, we should just drop it.
> > > 
> > > Performance advantage from MMX-copy-to-user is probably well worth it.
> > 
> > Stop this STUPID "it speeds things up" argument.
> > 
> > It's not TRUE.
> > 
> > We still have to do exactly the same things we do right now, because even
> > if we SIGSEGV we still have to return the right number of bytes
> > read/written. 
> > 
> > SIGSEGV doesn't mean that the system call wouldn't complete. It removes 
> > _none_ of the kernel fixup handling, because the SIGSEGV won't be 
> > delivered until we return to user mode anyway. So please stop mixing these 
> > two issues up.
> 
> If you pass bad pointer to memcpy(), you don't expect any reasonable
> return value, right?
> 
> So if you pass bad pointer to read(), why would you expect "number of
> bytes read" return? Its true that kernel can't simply not return
^^^^^^^^^^^^^^^^^^^^

Because read() may *consume* its input, while memcpy() it's only a copy and
leaves the source intact (if you care not to overlap src and dst).
If you're read()ing from a serial line with 1-byte fifo you want to
know how many chars you read successfully in the first place, since
once read, they're gone. SIGSEGVing won't help in re-reading the chars.

> anything, but giving SIGSEGV and returning -EFAULT seems pretty
> reasonable to me. If they really want to, they might extract number of
> bytes read from address SIGSEGV occured at [but that's dirty hack, and
> people will hopefully realise that and not rely on it].
> 								Pavel

.TM.