mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Al Viro <viro@ftp.linux.org.uk>
To: mfbaustx <mfbaustx@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: copy_from_user / copy_to_user with no swap space
Date: Mon, 16 Oct 2006 20:34:19 +0100	[thread overview]
Message-ID: <20061016193419.GE29920@ftp.linux.org.uk> (raw)
In-Reply-To: <op.thi3x1mvnwjy9v@titan>

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.

  parent reply	other threads:[~2006-10-16 19:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-16 19:19 mfbaustx
2006-10-16 19:28 ` Oliver Neukum
2006-10-16 19:47   ` mfbaustx
2006-10-17 10:58     ` Horst H. von Brand
2006-10-17 12:00     ` Helge Hafting
2006-10-16 19:34 ` Al Viro [this message]
2006-10-16 19:39 ` Kyle Moffett
2006-10-16 20:26   ` mfbaustx
2006-10-16 20:21 ` Horst H. von Brand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20061016193419.GE29920@ftp.linux.org.uk \
    --to=viro@ftp.linux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mfbaustx@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome