[lkml]   [2006]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: copy_from_user / copy_to_user with no swap space
    On Mon, Oct 16, 2006 at 02:19:03PM -0500, mfbaustx wrote:
    > stacks start high and grow down. Somewhere in there you get your heap and
    > shared memory regions. Since noting about a logical address can identify
    > a specific process, then copy_to/from_user can do nothing to guaruntee
    > that the CORRECT process is paged in. True? So you're absolutely
    > obligated to DO the copy at the time the kernel is executing on behalf of
    > that process. Once your process/thread is context swapped, you've lost
    > the [correct] information on the address mapping.
    > So, IF you MUST copy_from/to_user when in the context of the process, AND
    > IF you have no virtual memory/swapping, THEN must it not be true that you
    > can ALWAYS dereferences your user space pointers?

    First of all, kernel and userland don't have to be in the same address
    space at all; not even on x86 in some configuration. So dereferencing
    user pointer as if it had been a normal pointer simply won't work - what
    you'll get might have nothing to do with any user memory.

    But even aside of that, even on architectures where kernel and userland
    _do_ share address space, there's nothing to guarantee that any given
    piece of user address space is currently present or has ever been paged
    in to start with.

    Dereference that and you'll get an exception. If you take a look at
    the guts of e.g. arch/i386/lib/usercopy.c, you'll see stuff going to
    .fixup section; when you call e.g. get_user() on address in a page that
    is currently not paged in, exception *is* generated and handled; then
    control is returned back to where we'd taken it.

    IOW, even low-level code on such targets has to be careful; blind dereferencing
    would simply get you an oops. On something like ppc it's simply out of
    question - there you would be able to trigger reads from memory-mapped
    registers of hell knows what hardware. From userland. Confusing the
    living fsck out of hardware and drivers... _And_ you'd get access to
    genuine kernel data.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-10-16 21:37    [W:0.020 / U:68.240 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site