Re: 2.6.19, more unwinder problems ...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>> Ingo Molnar <[email protected]> 15.12.06 12:24 >>>
>
>* Jan Beulich <[email protected]> wrote:
>
>> validating that the item read is between current and previous stack 
>> pointer, which in turn are being derived from register state and 
>> unwind information.
>
>i still dont quite get it - and i feel deja vu. Didnt we agree that the 
>right way to go about this is to validate all stack information based on 
>what the kernel already knows about all the stacks that the task may 
>use? I.e. only allow pointers into the kernel stack and into the various 
>kernel stacks. No 'probe kernel pointer' or anything. If the unwind data 
>or register state ever points outside that basic filter, abandon the 
>walk. Am i missing something?

No, we didn't agree on this. Linus asked me to, but I didn't agree (Andi
seemed to tend towards Linus' opinion), based on my intentions of rather
(mid to long term) removing all this a priori knowledge of what stacks may
be switched from/to. Also, I think a filter like you suggest can far too
easily get out of sync with reality (as an example, on i386 I had long ago
submitted a patch to enhance the double fault handling, which hadn't
been rejected with a reason but also wasn't picked up - in that light I
would immediately question whether the double fault stack, in anticipation
of the double fault handler hopefully calling the unwinder rather sooner
than later to get out information, if possible, on what lead to the double
fault, should be treated positively by that filter, and whether, once that
stack finally gets converted to a per-CPU ones, it would be remembered
to update the filter accordingly).

Basically, as I stated before, I wouldn't try to veto a change that does
that (especially under the impression that my opinion here doesn't seem
to count), but I would neither put me as Signed-off-by or Acked-by
under it.

Jan
-
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/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux