lkml.org 
[lkml]   [2009]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    SubjectRe: [PATCH] asm-generic: uaccess: fix up local access_ok() usage
    Date
    On Saturday 13 June 2009, Mike Frysinger wrote:
    > There's no reason that I can see to use the short __access_ok() form
    > directly when the access_ok() is clearer in intent and for more people,
    > expands to the same C code (i.e. always specify the first field -- access
    > type). Not all no-mmu systems lack memory protection, so the read/write
    > could feasibly be checked.

    Ah, I didn't consider this. I checked all the architectures and could not
    find a case where access_ok actually evaluates the the first argument, so
    I chose the slightly terser variant. I also don't let you override
    access_ok() at this moment, which means that you don't have a choice
    to use the generic uaccess.h and still differentiate between read and
    write accesses.

    What I really got wrong was the prototype for __access_ok(), as you
    showed in your follow-up. I only tested this with the microblaze
    patch that overrides __access_ok() with an architecture specific
    version that gets this part right.

    Would this simpler patch help you as well?

    --- a/include/asm-generic/uaccess.h
    +++ b/include/asm-generic/uaccess.h
    @@ -37,14 +37,14 @@ static inline void set_fs(mm_segment_t fs)
    #define VERIFY_READ 0
    #define VERIFY_WRITE 1

    -#define access_ok(type, addr, size) __access_ok((unsigned long)(addr),(size))
    +#define access_ok(type, addr, size) __access_ok((addr), (size))

    /*
    * The architecture should really override this if possible, at least
    * doing a check on the get_fs()
    */
    #ifndef __access_ok
    -static inline int __access_ok(unsigned long addr, unsigned long size)
    +static inline int __access_ok(void __user *ptr, unsigned long size)
    {
    return 1;
    }
    It may not be clearer in intent, but it's what the majority (by a small
    margin) of architecture do anyway.

    > Also, the strnlen_user() function was missing a access_ok() check on the
    > pointer given. We've had cases on Blackfin systems where test cases
    > caused kernel crashes here because userspace passed up a NULL/-1 pointer
    > and the kernel gladly attempted to run strlen() on it.

    Right, well spotted. I'll take this fix as a separate patch, ok?

    Arnd <><


    \
     
     \ /
      Last update: 2009-06-13 22:57    [W:0.023 / U:181.152 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site