lkml.org 
[lkml]   [1998]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: copy_from_user() fixu
H. Peter Anvin writes:
> > H. Peter Anvin writes:
> > > >
> > > > Well, being serious here, I have a library that is bug-free, but I
> > > > can't depend on application writers to sustain my level of
> > > > perfection. So, so help these lesser beings, I trap EFAULT in my
> > > > library and yield a more meaningful diagnostic than a mere EFAULT or
> > > > SEGV.
> > >
> > > Now you *really* convinced me that you're crazy.
> >
> > Why not insult me further while you're at it?
>
> You claimed you have a library that's bug-free, and you're relying on
> undefined behaviour. Clearly, your definition of "bug-free" is
> something different than us "lesser beings" use.

Sigh. I should have put a smiley there. The serious point I was making
was that I can't determine what pointers the application will pass.

> > > Once again: if you're relying on EFAULT rather than SIGSEGV, your code
> > > is broken, as you're relying on details of the libc/kernel interface.
> > > I would argue that *IS* a bug in your "bug-free" library.
> >
> > I'm relying on what I've seen written in man pages for all varieties
> > of Unix I've had access to.
>
> Yes, it says that it's a PERMITTED return value, which is
> fundamentally different from GUARANTEED.
>
> > This abstract libc/kernel interface you refer to is an abstraction
> > you've invented. It's not Unix practice. Unix practice is to return
> > EFAULT on system calls. System calls are open(2), read(2), write(2)
> > and similar.
>
> I didn't invent it. It has been in every single Unix spec I've ever
> read, and it's very explicit.

I'm staring at the read(2) man page for Solaris 2.5 and it talks about
EFAULT. I don't see where it implies that EFAULT is optional.

> > > If you want to trap errors, you either have to sanitize the input, or
> > > trap SIGSEGV.
> >
> > I can't sanitise the input: I don't know what pointer the application
> > will pass. Trapping SEGV is a performance bugger: I have to install a
> > signal handler before every pseudo-syscall and restore it afterwards
> > (my library can't steal signals).

You haven't responded to this part. Wrapping *every* call to read(2)
with a signal/setjmp save/restore is a performance killer.
Can you actually be serious that an application/library that tries to
trap bad addresses has to put up with this?

Regards,

Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.097 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site