Theo de Raadt wrote:
>Otto Moerbeek <o...@drijf.net> wrote:
>> Fixing a particluar issue is fine, but more important is an assessment
>> it does not break other things. In particular, does this limit the VM
>> for data available to any program (which is already quite limited on
>> i386)?
MAXTSIZ is used in one and only one place in the whole CVS tree, in the
file sys/kern/kern_exec.c:
int
check_exec(struct proc *p, struct exec_package *epp)
{
[...]
/* check limits */
if ((epp->ep_tsize > MAXTSIZ) ||
(epp->ep_dsize > lim_cur(RLIMIT_DATA)))
error = ENOMEM;
[...]
So doubling MAXTSIZ won't increase or decrease any other kernel limit, and
won't drastically change the placement of anything in virtual memory.
>I am concerned about the impact this might have on binaries and shared
>libraries fitting, because of the i386 line-in-the-sand code and data
>seperation model for pre-NX W^X, binaries and libraries are intended
>to fit into 512MB seperation, and if they cannot, then the X line ends up
>being very high.
I guess you're referring to I386_MAX_EXE_ADDR in
sys/arch/i386/include/vmparam.h? I'm not knowledgeable enough to
meaningfully comment on that. The only extra thing I can say in favor of
bumping up MAXTSIZ to 256 MB is that NetBSD increased MAXTSIZ from 64 MB
straight to 256 MB more than eight years ago (see Revision 1.74):
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/i386/include/vmparam.h?only_with_tag=MAIN
(MAXTSIZ currently is 128 MB on FreeBSD.)
Philippe
