RE: Kernel stack

From: Dhiman, Gaurav (Gaurav.Dhiman_at_ca.com)
Date: 10/13/04

  • Next message: suthambhara nagaraj: "Re: Getting a process' EIP address (and other registers)" 
    Date:	Wed, 13 Oct 2004 10:05:15 +0530
To: "Jan Hudec" <bulb@ucw.cz>, "aq" <aquynh@gmail.com>

    You discussed that kernel do not keep track of SS for process specific
    kernel stack as it always starts from fixed offset of task_struct, but
    does that mean, linux kernel do not make use of SS element in the TSS of
    process. I think the kernel can not by-pass the rules defined by
    processor. Processor expects the SS and SP elements to be right at the
    time of stack switching, so we need to initialize them to the right
    values while forking a process.

    I think kernel definitely keep tracks of SS and SP for all CPU levels
    including kernel mode also (ring 0), so that when we are switching form
    user space to kernel space the processor can switch the stacks
    automatically. At stack switching time CPU expects the SS and SP
    elements of TSS to be right, it's just going to copy those values in SS
    and SP registers of CPU, so that now we can push and pop the things on
    the kernel stack.

    Yes it definitely can happen (and I think this is the way to do it) that
    SS in process's TSS is initialized to the memory address just next to
    task_struct (as the kernel stack can grow downwards till this limit)
    while the forking of a process and also sets the SP to the fixed offset
    from task_struct from where the kernel stack starts growing downwards
    (as you mentioned kernel stack starts from there). Now whenever this
    process will be scheduled by the scheduler or a process enters the
    kernel mode, CPU's SS and SP registers are re-set to the SS and SP
    elements in TSS of that process.

    At the time of scheduling, scheduler also change the TSS descriptor for
    that CPU on which the process is going to be scheduled. It changes this
    TSS descriptor in GDT to point to the TSS of the selected process.

    Correct me if I am wrong.

    Cheers !!
    Gaurav

    -----Original Message-----
    From: Jan Hudec [mailto:bulb@vagabond.light.src] On Behalf Of Jan Hudec
    Sent: Tuesday, October 12, 2004 6:42 PM
    To: aq
    Cc: suthambhara nagaraj; Dhiman, Gaurav; main kernel; kernel
    Subject: Re: Kernel stack

    On Tue, Oct 12, 2004 at 21:30:54 +0900, aq wrote:
    > > > >From what you all discuss, I can say: kernel memory is devided
    into 2
    > > > part, and the upper part are shared between processes. The below
    part
    > > > (the kernel stack, or 8K traditionally) is specifict for each
    process.
    > > >
    > > > Is that right?
    > >
    > > No, it's not. There is just one kernel memory. In it each process
    has
    > > it's own task_struct + kernel stack (by default 8K). There is no
    special
    > > address mapping for these, nor are they allocated from a special
    area.
    > >
    > > When a context of some process is entered, esp is pointed to the top
    of
    > > it's stack. That's exactly all it takes to exchange stacks.
    >
    > OK, lets say there are 20 processes running in the system. Then the
    > kernel must allocate 20 * 8K = 160K just for the stacks of these
    > processes. All of these 160K always occupy the kernel (kernel memory
    > is never swapped out). When a process actives, ESP would switch to
    > point to the corresponding stack (of that process).

    This is correct.

    > The remainding memory of kernel therefore is equally accessible to all
    > the processes.

    This is not. There is nothing like "remaining memory". **ALL* kernel
    memory is equally accessible to all the processes.

    There is noting special about the stacks and task-structs. They are
    normal 8K structures somewhere in kernel memory.

    > Is that correct ?

    ------------------------------------------------------------------------
    -------
                                                     Jan 'Bulb' Hudec
    <bulb@ucw.cz>
    -
    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/

  • Next message: suthambhara nagaraj: "Re: Getting a process' EIP address (and other registers)"

    Relevant Pages

    • [Full-disclosure] PHRACK 64: ATTACKING THE CORE
      ... - The Slab Allocator ... - Slab overflow exploiting: ... - Forcing a kernel path to sleep ... - Stack Frame Flow Recovery ...
      (Full-Disclosure)
    • Re: Kernel stack
      ... The problem is each process does not have a TSS of its own.Only one ... in another structure.A kernel stack of size 8k ... esp entry. ... This made me believe that the stack base is the ...
      (Linux-Kernel)
    • Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
      ... stack usages for you is that they contain a 'cpumask_t' on the stack. ... We can enable MAXSMP and raise the CPU limits some time in the future. ... not accept a specially built kernel, but only a kernel that has been ... know how extensively these distributions test and certify for many known ...
      (Linux-Kernel)
    • Re: Interrupt context...
      ... > gone through most of the posts on interrupt in usenet. ... > kernel stack and ISR is executed. ... More may be saved depending on the architecture. ... Here the kernel have assembler code to save all general ...
      (comp.os.linux.development.system)
    • Re: The Linux Staging tree, what it is and is not.
      ... if you compromize them and write the wrong ones to the stack, ... Load two user space fieldbus stacks on the same network card (remembering ... right, but that's the same, no matter if it runs in kernel or user ... need an objdict API to userspace...? ...
      (Linux-Kernel)