verify_area() question

verify_area() question

Post by Kuang-Chun Che » Thu, 08 Jan 1998 04:00:00



Hi,

   As my understanding (by reading "LINUX Kernel Internals"), whenever
we call put_user, get_user, memcpy_tofs or memcpy_fromfs, we should call
verify_area() first to make sure we can read/write data from/to user
space.  But looking at the source code of linux/drivers/char/mem.c, we
can't find verify_area() there (2.0.27) which should be NECESSARY as
"LINUX Kernel Internals" said.  So ...?  Do I loss some important stuff?
Need comments and Thanks.

                               Kuang-chun Cheng

 
 
 

verify_area() question

Post by a.. » Thu, 08 Jan 1998 04:00:00



> Hi,

>    As my understanding (by reading "LINUX Kernel Internals"), whenever
> we call put_user, get_user, memcpy_tofs or memcpy_fromfs, we should call
> verify_area() first to make sure we can read/write data from/to user
> space.  But looking at the source code of linux/drivers/char/mem.c, we
> can't find verify_area() there (2.0.27) which should be NECESSARY as
> "LINUX Kernel Internals" said.  So ...?  Do I loss some important stuff?
> Need comments and Thanks.

The verify_area() is already done by higher VFS layers (see
fs/read_write.c:sys_read and sys_write)

-Andi

 
 
 

verify_area() question

Post by Kuang-Chun Che » Thu, 08 Jan 1998 04:00:00



: >    As my understanding (by reading "LINUX Kernel Internals"), whenever
: > we call put_user, get_user, memcpy_tofs or memcpy_fromfs, we should call
: > verify_area() first to make sure we can read/write data from/to user
: > space.  But looking at the source code of linux/drivers/char/mem.c, we
: > can't find verify_area() there (2.0.27) which should be NECESSARY as
: > "LINUX Kernel Internals" said.  So ...?  Do I loss some important stuff?
: > Need comments and Thanks.

: The verify_area() is already done by higher VFS layers (see
: fs/read_write.c:sys_read and sys_write)

: -Andi

Hi Andi,

    Yes, you are right.  The verify_area() is done in syscall layer or
as you said, higher VFS layer.  Since all the user programs should access
device driver through syscall interface, looks like we can safely remove
all verify_area() from device driver code.  Is this statement correct?
There are a lot of verify_area() used in device drivers ...  why do this
kind of check twice?  Anyway, thanks.

                                 Kuang-chun Cheng

 
 
 

verify_area() question

Post by a.. » Fri, 09 Jan 1998 04:00:00




> : >    As my understanding (by reading "LINUX Kernel Internals"), whenever
> : > we call put_user, get_user, memcpy_tofs or memcpy_fromfs, we should call
> : > verify_area() first to make sure we can read/write data from/to user
> : > space.  But looking at the source code of linux/drivers/char/mem.c, we
> : > can't find verify_area() there (2.0.27) which should be NECESSARY as
> : > "LINUX Kernel Internals" said.  So ...?  Do I loss some important stuff?
> : > Need comments and Thanks.

> : The verify_area() is already done by higher VFS layers (see
> : fs/read_write.c:sys_read and sys_write)

> : -Andi

> Hi Andi,

>     Yes, you are right.  The verify_area() is done in syscall layer or
> as you said, higher VFS layer.  Since all the user programs should access
> device driver through syscall interface, looks like we can safely remove
> all verify_area() from device driver code.  Is this statement correct?
> There are a lot of verify_area() used in device drivers ...  why do this
> kind of check twice?  Anyway, thanks.

It is not checked in all cases, e.g. for ioctls the driver is generally
responsible for checking it (because there are far too many and too diverse
ioctls to do it generally). In 2.1 most of the work of verify_area() has
been moved into the exception handler anyways, because the 2.0 way of
verify_area involves races with threads that use munmap() (and with SMP,
although that isn't an issue in 2.0 because of the global kernel lock).

-A.

 
 
 

1. Question on verify_area() and friends wrt

Hi,

I've been taking care of auditing some return values for instances of
unchecked copy_*_user calls and I've come across one case that's
marked as a bug at kbugs.org which however doesn't seem like one to me.
The piece of code I'm referring can be found in
net/bluetooth/hci_core.c:436

if (!verify_area(VERIFY_WRITE, ptr, sizeof(ir) +
                (sizeof(struct inquiry_info) * ir.num_rsp))) {
    copy_to_user(ptr, &ir, sizeof(ir));
    ptr += sizeof(ir);
    copy_to_user(ptr, buf, sizeof(struct inquiry_info) * ir.num_rsp);   } else
    err = -EFAULT;

I'm presuming verify_area() does its job fine returning 0 if the memory
is valid and -EFAULT if not. Thus, given the exact check that's been
done, there seems indeed to exist no need to check each call to
copy_to_user() below. Or is there?

Thanks in advance,

                Paulo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. Getting Staroffice 52 to work with CUPS 1.1

3. verify_area return values

4. Hello Solaris Gods!!

5. How exact works verify_area ?

6. setting up network with multiple domain names

7. Is verify_area required in IOCTL call?

8. Voice recording

9. PATCH: fix cosa verify_area

10. verify_area(..) error

11. verify_area() fails!

12. verify_area(..) error

13. ftape (verify_area)