Can we just put a canary in the threadinfo and check it on every
task switch? What are the drawbacks?
I guess most stack corruptions touch only a small part of the stack.
These kinds of corruptions can only be detected from inside the
program.
Anyway, going beyond the program's stack boundaries would fault the program.
Checking the threadinfo constantly it'll be (IMHO) mostly useless...
On 2/28/07, Chuck Ebbert <[email protected]> wrote:
> Can we just put a canary in the threadinfo and check it on every
> task switch? What are the drawbacks?
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
-
Thiago Galesi
On Wed, Feb 28, 2007 at 09:27:09AM -0500, Chuck Ebbert wrote:
> Can we just put a canary in the threadinfo and check it on every
> task switch? What are the drawbacks?
Likely already too late then -- if critical state is overwritten
you crashed before. Also a lot of stack intensive codes
relatively large unused holes so it might miss the canary completely
Anyways if you want a crash on context switch in the non
hole case you can probably get it by just rearranging thread_info a bit.
e.g. put preempt_count first. Any corruption of that will lead
to schedule complaining.
Don't think it is worth it though.
I suppose one could have a CONFIG_DEBUG_STACK_OVERFLOW that gets
the stacks from vmalloc which would catch any overflow with its
guard pages. This is you would need to change __pa() to handle
that too because there might be still some drivers that do
DMA on stack addresses. Would be somewhat ugly but doable.
But I have my doubts it is worth it again -- in my experience static
analysis works well enough to trace them down and
there are not that many anyways.
-Andi
On Wed, Feb 28, 2007 at 09:41:44PM +0100, Andi Kleen wrote:
> Likely already too late then -- if critical state is overwritten
> you crashed before. Also a lot of stack intensive codes
> relatively large unused holes so it might miss the canary completely
> Anyways if you want a crash on context switch in the non
> hole case you can probably get it by just rearranging thread_info a bit.
> e.g. put preempt_count first. Any corruption of that will lead
> to schedule complaining.
> Don't think it is worth it though.
> I suppose one could have a CONFIG_DEBUG_STACK_OVERFLOW that gets
> the stacks from vmalloc which would catch any overflow with its
> guard pages. This is you would need to change __pa() to handle
> that too because there might be still some drivers that do
> DMA on stack addresses. Would be somewhat ugly but doable.
> But I have my doubts it is worth it again -- in my experience static
> analysis works well enough to trace them down and
> there are not that many anyways.
I don't know about the rest of the world, but halting the system in the
case of memory corruption sounds like an extremely good idea to me.
-- wli
On Feb 28 2007 15:20, Bill Irwin wrote:
>
>I don't know about the rest of the world, but halting the system in the
>case of memory corruption sounds like an extremely good idea to me.
Just because a rather "unimportant" driver (e.g. parport) might oops
thanks to a now-invalid address after memory corruption, I'd still like
to shutdown the system normally - which should be possible when not
using parport after said corruption.
Jan
--
ft: http://freshmeat.net/p/chaostables/
On Feb 28 2007 15:20, Bill Irwin wrote:
>> I don't know about the rest of the world, but halting the system in the
>> case of memory corruption sounds like an extremely good idea to me.
On Thu, Mar 01, 2007 at 12:36:47AM +0100, Jan Engelhardt wrote:
> Just because a rather "unimportant" driver (e.g. parport) might oops
> thanks to a now-invalid address after memory corruption, I'd still like
> to shutdown the system normally - which should be possible when not
> using parport after said corruption.
Panic on oops/bug is sysctl-activated as things now stand, so you're
all set.
-- wli