What is the point of using the linux macro access_ok()

Question

I've been doing some research and I'm a little confused about this macro. Hopefully someone can give me some guidance. I have some ioctl code (which I've inherited, not written) and the first thing it does if check if access_ok() before moving on to copying data over from user space:

#define __lddk_copy_from_user(a,b,c) copy_from_user(a,b,c)
#define __lddk_copy_to_user(a,b,c) copy_to_user(a,b,c)

long can_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
  switch(cmd) {
    case COMMAND:
      if(! access_ok(VERIFY_READ, (void *)arg, sizeof(Message_par_t)))
        return(retval); 

      if(! access_ok(VERIFY_WRITE, (void *)arg, sizeof(Message_par_t)))
        return(retval); 

      argp = &Command;
      __lddk_copy_from_user( (void *) argp,(Command_par_t *) arg, sizeof(Command_par_t));

So the code works just fine, but I'm not sure it's needed. The first question comes from this description of access_ok's return:

• The function returns non-zero if the region is likely accessible (though access may still result in -EFAULT). This function simply checks that the address is likely in user space, not in the kernel.

So this means that it really does nothing more then make sure the pointer we're checking against is probably initialized in user space? Since we know that we couldn't come into this function other than a user space call, and it couldn't happen unless we opened a valid file descriptor to this device, is this really needed? Is it really any safer then just making sure we didn't get a NULL pointer?

Second question comes from this description:

• The type argument can be specified as VERIFY_READ or VERIFY_WRITE. The VERIFY_WRITE symbolic also identifies whether the memory region is readable as well as writable.

Does this mean the first check in my code is redundant? If we're going to check for a writable area we get readable as a freebie?

I'm using a x86 architecture so the definations of access_ok() and __range_no_ok() are those from /usr/src/linux-3.1.10-1.16/arch/x86/include/asm/uaccess.h as follows:

#define access_ok(type, addr, size) (likely(__range_not_ok(addr, size) == 0))

#define __range_not_ok(addr, size)                  \
({                                  \
    unsigned long flag, roksum;                 \
    __chk_user_ptr(addr);                       \
    asm("add %3,%1 ; sbb %0,%0 ; cmp %1,%4 ; sbb $0,%0"     \
        : "=&r" (flag), "=r" (roksum)               \
        : "1" (addr), "g" ((long)(size)),               \
          "rm" (current_thread_info()->addr_limit.seg));        \
    flag;                               \
})

Answer 1

If __lddk_copy_from_user() simply calls copy_from_user(), then the access_ok() checks are redundant, because copy_from_user() performs these checks itself.

The access_ok() checks ensure that the userspace application isn't asking the kernel to read from or write to kernel addresses (they're an integrity/security check). Just because a pointer was supplied by userspace doesn't mean that it's definitely a userspace pointer - in many cases "kernel pointer" simply means that it's pointing within a particular region of the virtual address space.

Additionally, calling access_ok() with VERIFY_WRITE implies VERIFY_READ, so if you check the former you do not need to also check the latter.

---

As of this commit in 2019, access_ok() no long has the type argument, so the VERIFY_WRITE versus VERIFY_READ point is moot.