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
