Messages in this thread | | | Date | Wed, 03 May 2006 09:08:31 +0200 | From | "Jan Beulich" <> | Subject | Re: 2.6.17-rc2-mm1 |
| |
>> ><EOE>new stack 0 (0 0 0 10082 10) >> >> Looks like <rubbish> <SS> <RSP> <RFLAGS> <CS> to me, ... > >Hmm, right. > >> >Hmm weird. There isn't anything resembling an exception frame at the top of the >> >stack. No idea how this could happen. >> >> ... which is a valid frame where the stack pointer was corrupted before the exception occurred. One more printed item >> (or rather, starting items at estack_end[-1]) would allow at least seeing what RIP this came from. > >Any can you add that please and check?
???
>Also worst case one could dump last branch pointers. AMD unfortunately only has four, >on Intel with 16 it's easier.
Provided you disable recording early enough. Otherwise only one (last exception from/to) is going to be useful on both.
>I can provide a patch for that if needed. > >> This actually points out another weakness of that code: if you pick up a mis-aligned stack pointer then the conditions >> in both the exception and interrupt stack invocations of HANDLE_STACK() won't prevent you from accessing an item >> crossing a page boundary, and hence potentially faulting. > >Yes it probably should check for that. > >> Similarly, obtaining an entirely bad stack pointer anywhere in >> that code will result in a fault. I guess the stack reads should really be done using get_user() or some other code >> having recovery attached. > >That can cause recursive exceptions. I'm a bit paranoid with that.
Without doing so it can also cause recursive exceptions, just that this is going to be deadly then.
Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |