Randomized stack location in RedHat 9

From: Michael Zhivich (mikez_at_mit.edu)
Date: 04/26/04

  • Next message: Kasper Dupont: "Re: Randomized stack location in RedHat 9" 
    Date: 26 Apr 2004 10:30:40 -0700

    Hello,

    I'm running RedHat 9 (Shrike) kernel, and I've noticed that the stack
    location is randomized over 64 different adresses ranging from about
    0xBFFD9000 to 0xBFFD000.

    I was wondering if there is a way to turn this randomization off -
    i.e. I would like to have the stack start at the same location for
    consecutive executions of the same program (I'm running some repeated
    tests, and stack randomization makes it difficult to interpret the
    results). As far as I can tell, the kernel has neither grsecurity
    patches nor ExecShield. I have read about a similar stack
    randomization patch for OpenBSD, but can't seem to find any info on
    such a patch being added to the RedHat kernel.

    Any help would be greatly appreciated.

    Thanks,
    ~ Michael
      mikez@mit.edu

  • Next message: Kasper Dupont: "Re: Randomized stack location in RedHat 9"

    Relevant Pages

    • Re: [PATCH] 2.6.16.16 Parameter-controlled mmap/stack randomization
      ... stack pointer within the first page. ... If it's 0, no randomization happens. ... The kernel command line parameter could be removed as soon as SELinux ... architectures react differently in terms of randomization; ...
      (Linux-Kernel)
    • Re: Randomized stack location in RedHat 9
      ... I never noticed that while I was using Red Hat ... > I was wondering if there is a way to turn this randomization off - ... and stack randomization makes it difficult to interpret the ... As far as I can tell, the kernel has neither grsecurity ...
      (comp.os.linux.development.system)
    • [PATCH] 2.6.16.16 Parameter-controlled mmap/stack randomization
      ... I'm trying to control the stack and heap randomization via command-line ... I wrote this in a 2.6.15 Ubuntu Dapper kernel and then ... if we move to something with that level of entropy ...
      (Linux-Kernel)
    • [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: [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)