Re: verify_area(...) possible problem.

Linus Torvalds (torvalds@transmeta.com)
13 Apr 1999 17:00:10 GMT


In article <4B857AEEE602D211A45900805FA7753C0407D1@TOTOMB02>,
Gilbert, Douglas <douglas.gilbert@rbcds.com> wrote:
>
>Linus Torvalds wrote:
>
>> ... you can do
>>
>> error = access_ok(VERIFY_READ, p, 3*sizeof(*p));
>> if (!error) {
>> __put_user(a, p);
>> __put_user(b, p+1);
>> __put_user(c, p+2);
>> }
>>
>> where the __xxx versions are faster but "unsafe" unless you have
>> verified the area by hand first.
>
>Can this be extended to:
>
> error = access_ok(VERIFY_READ, p, 3*sizeof(*p));
> if (! error) {
> interruptible_sleep_on(&some_wait_queue);
> ...
> __put_user(a, p);
> __put_user(b, p+1);
> __put_user(c, p+2);
> }
>??

Yes.

"access_ok()" really only checks that the pointer is a _potentially_
valid user space pointer. What that means is architecture-dependent, as
user-space pointers can have different representations on different
architectures, but on the x86, for example, it only checks that the
pointer is within the "TASK_SIZE" thing (ie in the region 0-0xbfffffff
on a default linux kernel).

On other architectures "access_ok()" can actually be a no-op, because
the user address space can be completely separate from the kernel
address space and is accessed with special instructions rather than with
a normal load/store like on the x86.

As such, "access_ok()" is not timing-related, and it doesn't matter
whether you do it immediately before the access or a year before.
That's a requirement to actually be thread-safe, so this is very much a
fundamental design decision.

The test whether a page is actually _mapped_ within the user address
space is then done when doing the actual access. On any sane
architecture this is done by the hardware mmu, and the only thing the
get_user()/put_user() functions need to do is to set up everything so
that the kernel page fault handler can recover gracefully from any
faults.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/