Re: The 64-bit version of __access_ok is broken.

[Ralf Baechle <ralf@linux-mips.org>]

On Mon, Dec 09, 2002 at 11:54:20AM +0000, Dominic Sweetman wrote:

> I'd like to be clear about the consequences of this.  Presumably the
> 'access_ok()' macro is used to check addresses which were (originally)
> provided by a user program's system call.
> 
> Carsten, are you saying that if such an address is set to say 2**41 in
> a CPU supporting 40-bit user virtual addresses, that the kernel will
> crash?

That's correct.  The problem which Carsten diagnosed correctly was the
assumption which has been inherited from the 32-bit kernel that the sign-
bit makes the difference between valid userspace and kernelspace
addresses.

Linux doesn't use the supervisor mode so basically that assumption is still
true with the except of the area 2^PHYSBITS ... 2^63-1.

> If so, that seems to require a fix, even if we don't know a very
> efficient one.  But perhaps any problem is a bit more subtle than
> that?

Access_ok is a macro which depending on kernel configuration is expanded
hundreds, if not thousands of times throughout the kernel.  So every single
machine instruction in access_ok will make a size difference of several
kB.  Carsten's patch was performing pretty badly in that cathegory.  If
access_ok wasn't used that often the issue certainly wasn't worth the fuzz.

Access_ok is of course only usable in C code.  We also have a few piece of
assembler code that access userspace and need to perform the same kind of
address validation tests.  Carsten's patch was missing these completly.  As
such it did only reduce the window of this bug from huge to "just" big.

An efficient solution only requires fairly minor changes as you can see in
the patch I just posted.  It doesn't even require thinking, it can be
obtained by cut'n'paste from the Alpha code.  Alternatively the problem
could also have been solved by forwarding address errors for the address
range in question to the page fault handler which would have served the
same purpose, maybe even a tad more efficient but ofuscated ...

  Ralf