Re: copy_from_user / copy_to_user with no swap space

[Al Viro]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/