]> git.baikalelectronics.ru Git - kernel.git/commit
sparc64: Validate kernel generated fault addresses on sparc64.
authorDavid S. Miller <davem@davemloft.net>
Tue, 3 Feb 2009 06:08:15 +0000 (22:08 -0800)
committerDavid S. Miller <davem@davemloft.net>
Tue, 3 Feb 2009 06:08:15 +0000 (22:08 -0800)
commitff753ca1d921283ef342c3eea81d5577b0c24b36
tree9e15ca81917df4c980b29c54091f909bdc868138
parent88d938499762ebd37c83a51ee7e3d4ff00c00131
sparc64: Validate kernel generated fault addresses on sparc64.

In order to handle all of the cases of address calculation overflow
properly, we run sparc 32-bit processes in "address masking" mode
when running on a 64-bit kernel.

Address masking mode zeros out the top 32-bits of the address
calculated for every load and store instruction.

However, when we're in privileged mode we have to run with that
address masking mode disabled even when accessing userspace from
the kernel.

To "simulate" the address masking mode we clear the top-bits by
hand for 32-bit processes in the fault handler.

It is the responsibility of code in the compat layer to properly
zero extend addresses used to access userspace.  If this isn't
followed properly we can get into a fault loop.

Say that the user address is 0xf0000000 but for whatever reason
the kernel code sign extends this to 64-bit, and then the kernel
tries to access the result.

In such a case we'll fault on address 0xfffffffff0000000 but the fault
handler will process that fault as if it were to address 0xf0000000.
We'll loop faulting forever because the fault never gets satisfied.

So add a check specifically for this case, when the kernel is faulting
on a user address access and the addresses don't match up.

This code path is sufficiently slow path, and this bug is sufficiently
painful to diagnose, that this kind of bug check is warranted.

Signed-off-by: David S. Miller <davem@davemloft.net>
arch/sparc/mm/fault_64.c