Messages in this thread | | | Date | Tue, 25 Aug 1998 18:21:11 +1000 | From | Richard Gooch <> | Subject | Re: 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
| |