Copying kernel stack in a generic way

[E.S. Rosenberg]

Don't new security features like memory location randomization etc. kind of
get in the way of what you want to do on any modern OS?

(The way I understand it you are trying to copy the stack from outside the
running/frozen OS).

Regards,
Eliyahu - אליהו

2014-12-21 21:22 GMT+02:00 Elazar Leibovich <elazarl at gmail.com>:

> It could very well be the case,
> I just want to clarify, the reason I need the stack, is for
> analyzing/debugging/profiling later by OS specific tools. So it is OK
> to err on some pathological cases.
>
> If you have a concrete idea that would fit many Linux versions - I'll
> be happy to hear about it.
>
> On Sun, Dec 21, 2014 at 12:19 PM, Omer Zak <w1 at zak.co.il> wrote:
> > I think that any serious approach would include code for identifying the
> > OS and OS version in question, and using this information to find the
> > kernel stack.
> >
> > Any generalized heuristic would risk missing pathological OS
> > configurations and new versions.
> >
> > On the other hand, reliance upon OS identification would at least enable
> > the user to call Support when he runs your code on an OS not identified
> > as a supported OS.
> >
> > --- Omer
> >
> >
> > On Sun, 2014-12-21 at 11:08 +0200, Elazar Leibovich wrote:
> >> Thanks,
> >>
> >> On Sun, Dec 21, 2014 at 9:27 AM, Muli Ben-Yehuda <mulix at mulix.org>
> wrote:
> >> > On Fri, Dec 19, 2014 at 02:19:07PM +0000, Elazar Leibovich wrote:
> >> >
> >> >> I know where the stack ends, but how can I know where it begins?
> >> >
> >> > What assumptions can you make? Can you run kernel code in the VM
> >> > (e.g., by cloning and restarting it)? Can you assume it's running
> >> > Linux and/or Windows? Can you assume the kernel was compiled with
> >> > frame pointers? Or is it a completely black box VM and you can't make
> >> > any assumptions about what's running inside?
> >>
> >> This is a very practical question.
> >>
> >> Yes, I can run a forth-based OS, which isn't even using C-like stack.
> >> But I need to solve a problem for most of the user, and I want to
> >> support any reasonable OS.
> >>
> >> So Windows and Linux is a must, freeBSD/Solaris is nice-to-have, and
> >> anything else is probably optional.
> >>
> >> I want to assume anything which would be reasonably portable across
> >> popular OSes.
> >>
> >> For example, you asked about frame pointers, assuming you meant I can
> >> follow ebps back, until I get invalid ebp address, assuming this is
> >> the head of the stack. I'm not sure if it's reasonable to assume most
> >> kernel would be compiled with frame pointers, so I'm not sure how
> >> valid would this heuristic be.
> >>
> >> I can run code in the guest context, and actually to fetch the stack
> >> I'll probably run code that would copy it from the host context, but I
> >> couldn't think of a way to fetch the stack, that wouldn't be too
> >> implementation-specific.
> >>
> >>
> >> > By the way, some OS's have separate interrupt stacks, so you may be on
> >> > an interrupt stack or on a regular stack.
> >> >
> >>
> >> Good point, but I think the heuristic should catch it as well.
> > --
> > If verbal consent is not obtained in triplicate, it is a date rape.
> > Asking permission constitutes harassment.
> >
> > My opinions, as expressed in this E-mail message, are mine alone.
> > They do not represent the official policy of any organization with which
> > I may be affiliated in any way.
> > WARNING TO SPAMMERS:  at http://www.zak.co.il/spamwarning.htmlDelay is
> the deadliest form of denial.    C. Northcote Parkinson
> > My own blog is at http://www.zak.co.il/tddpirate/
> >
> > My opinions, as expressed in this E-mail message, are mine alone.
> > They do not represent the official policy of any organization with which
> > I may be affiliated in any way.
> > WARNING TO SPAMMERS:  at http://www.zak.co.il/spamwarning.html
> >
>
> _______________________________________________
> Linux-il mailing list
> Linux-il at cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20141222/8fbc5543/attachment.html>