Philippe Meunier <meun...@ccs.neu.edu> wrote:
> 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.
That is incorrect. ld and ld.so get into the game and there is magic.
> >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.)
Those operating systems do not have the line-in-the-sand W^X code we
wrote. Will you list the executable sizing of Windows next?
You are trying to ignore the issue which is holding this up.
