]> pilppa.com Git - linux-2.6-omap-h63xx.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)
commiteeabac7386ca13bfe1a58afeb04326a9e1a3a20e
tree9e15ca81917df4c980b29c54091f909bdc868138
parent802c64b310e5b9dfda6cb50b850b962ed96a9e81
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