Re: [PATCH] arm: mm: Poison freed init memory

[Stephen Boyd]

On 01/05/2011 12:26 PM, Russell King - ARM Linux wrote:
> On Wed, Jan 05, 2011 at 11:47:25AM -0800, Stephen Boyd wrote:
>> Poisoning __init marked memory can be useful when tracking down
>> obscure memory corruption bugs. When a pointer is 0xCCCCCCCC in an
>
> That's a bad idea for a value.  With a 3GB page offset and 256MB or
> more memory, accesses to such an address will always succeed.
>
> There's two things to be considered when selecting a possible poison
> value:
>
> 1. what value is guaranteed to provoke an undefined instruction exception?
> 2. what value when used as an address and dereferenced is mostly always
>    going to abort?
>
> 1 for ARM mode implies an 0xe7fXXXfX value.  For Thumb mode 0xdeXX.  We
> use this space for breakpoints.
>
> 2 unfortunately depends on the platform. 

A coworker proposed we use a SWI instruction. We could do that if the
poison is 0xEF and then do something in the SWI handler where that
number causes us to blow up?

If I'm following correctly, point 1 is about __init functions and point
2 is about __initdata. I'm more concerned about __initdata because
__init functions called from non __init marked functions are usually
caught with section mismatch checks. Also, if we're jumping to
0xCCCCCCCC we're probably not in the text section of the kernel with a
3GB offset anymore, right? __initdata is easier to reference from
anywhere (ignoring function pointers) and it would definitely be nice to
find those invalid accesses quicker. For point 2, perhaps an unaligned
access would trigger sometimes?

Swapping the cheese for some cheese flavored poison is better than nothing.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

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