[XCSSA] updating a kernel without rebooting

[xcssa@xcssa.org]

Wow, nice can of 'api' beans and different software/hardware levels.

On an x86, in order to speed things up, Linux generally does not use
frame (stack) pointers (e.g. ebx) for functions. Solaris && Windows,
it's the other way around.
Hence, the OSDL spec.

On 8/18/06, xcssa-admin@xcssa.org <xcssa-admin@xcssa.org> wrote:
> On 8/17/06, xcssa-admin@xcssa.org <xcssa-admin@xcssa.org> wrote:
> > The general linux releases do NOT have a very stable/consistent system
> > level API (e.g. see solaris or 'windows') between OS releases, so, not
> > likely.
>
> Doesn't matter.  There's no problem here that installing a kernel and
> rebooting fixes.  If your application-level binaries don't work with a
> new kernel, then they don't work even if you reboot with that kernel.
> And I beg to differ about the API.  The Win32 API changes (in terms of
> adding) stuff all the time.  The fact is that Win32 can hide the
> differences by emulating the old API in its kernel mode "libraries",
> and userland apps look up the kernel level routines just like you
> would in user mode with a dynamic library.  If they want a new system
> call, they just add a new routine.  This is why all the Windows
> exploits have to know which version of Windows you're running, because
> they don't do symbol lookups like normal programs.

Historically, windows programs use a version of coff (static
complilation) vs. aforementioned dynamic compilation.

> They have to jump straight to memory addresses, which vary from release to release.
Statically compiled program is different type of patch than
dynamically compiled program.

> OTOH, in x86 Linux, the only "lookup" that is done is when a libc stub
> maps to a trap to kernel mode via int 0x80.

Or introduce one with int 13 && redirect to kernel

> The system call _number_
> is stored in EAX IIRC.  If someone wants to change the arguments or
> semantics of a system call, or add a new one, there is intense debate!
>  I don't recall exactly why right now (look at the time), but it was a
> good reason.  Maybe binary emulation on other OSes?
>
> g'nite!
> --
Or in short, windows apps see things from a kernel view vs. linux apps
seeing things at the user view.