Re: How to enable/disable security features on mmap() ?

["linux-os \(Dick Johnson\)" <linux-os@analogic.com>]

On Thu, 8 Dec 2005, Arjan van de Ven wrote:

>
>> Isn't this too much?  I thought the random-stack patch was
>> only supposed to vary it a page or 64k at most. This looks
>> like some broken logic because it varies almost 8 megabytes!
>
> that is correct; the 64k was only there for one patch proposal; linus'
> tree had 8 Mb randomisation from the start
>
>> No wonder some of my user's database programs sometimes seg-fault
>> and other times work perfectly fine. I think this is incorrect
>> and shows a serious bug (misbehavior).
>
> eh how? This 8Mb isn't eaten from the stack rlimit; the entire stack is
> moved, and the rlimit applies to the size not the position.

The stack moves down! It cannot go below the heap without destroying
malloc()ed buffers. I note that the heap also was "dynamically" moved
down to accommodate this, but its lower limit can't interfere with
_end[], the end of initialized data (fixed by the compiler and
data-size in the program).

0xbfbb6d74	Stack
0xb7e97008	Heap
0x80495e8	_end[]

An 8 megabyte variation is absolutely insane. It follows the "If a
little is good, more must be better..." theory. The purpose of
the random stack start, initially proposed by me BTW, was to
prevent stack-exploit code from being able to hard-code addresses
on the stack. Being off by one byte is enough, 8192 was originally
discussed and, I thought, adopted. Eight megabytes is absurd and has
no technical basis.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.
.

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.
-
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/