Re: execve -1 errno 12 Cannot allocate memory
Philippe Meunier wrote:
> Theo de Raadt wrote:
> >Otto Moerbeek 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.
Re: execve -1 errno 12 Cannot allocate memory
Theo de Raadt wrote:
>Otto Moerbeek 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
Re: execve -1 errno 12 Cannot allocate memory
Otto Moerbeek wrote: > On Mon, Feb 01, 2021 at 10:24:31PM -0500, Philippe Meunier wrote: > > > Anyone? > > 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)? Good of you to point that out of otto. 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. Of course we all have NX systems now, so that should not matter, but we should still see if the layout actually works. We never investigated these edge conditions.
Re: execve -1 errno 12 Cannot allocate memory
On Mon, Feb 01, 2021 at 10:24:31PM -0500, Philippe Meunier wrote: > Anyone? 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)? -Otto > > Philippe > > > Philippe Meunier wrote: > >Jonathan Gray wrote: > >>MAXTSIZ is 128 MB on i386 > >>see sys/arch/i386/include/vmparam.h > > > >Mark Kettenis wrote: > >>sys/arch/i386/include/vmparam.h has: > >>#define MAXTSIZ (128*1024*1024) /* max text size */ > > > >Thanks to both of you for the pointer! > > > >So what about the patch below? I've checked with a new kernel that it > >fixes the problem with chrome (even when using the default limits in > >/etc/login.conf). > > > >Philippe > > > > > >Index: sys/arch/i386/include/vmparam.h > >=== > >RCS file: /cvs/src/sys/arch/i386/include/vmparam.h,v > >retrieving revision 1.56 > >diff -u -r1.56 vmparam.h > >--- sys/arch/i386/include/vmparam.h 17 Apr 2018 15:50:05 - 1.56 > >+++ sys/arch/i386/include/vmparam.h 31 Jan 2021 09:41:00 - > >@@ -46,7 +46,7 @@ > > /* > > * Virtual memory related constants, all in bytes > > */ > >-#define MAXTSIZ (128*1024*1024) /* max text size */ > >+#define MAXTSIZ (256*1024*1024) /* max text size */ > > #ifndef DFLDSIZ > > #define DFLDSIZ (64*1024*1024) /* initial data size > > limit */ > > #endif > > > > >
Re: execve -1 errno 12 Cannot allocate memory
Anyone? Philippe Philippe Meunier wrote: >Jonathan Gray wrote: >>MAXTSIZ is 128 MB on i386 >>see sys/arch/i386/include/vmparam.h > >Mark Kettenis wrote: >>sys/arch/i386/include/vmparam.h has: >>#define MAXTSIZ (128*1024*1024) /* max text size */ > >Thanks to both of you for the pointer! > >So what about the patch below? I've checked with a new kernel that it >fixes the problem with chrome (even when using the default limits in >/etc/login.conf). > >Philippe > > >Index: sys/arch/i386/include/vmparam.h >=== >RCS file: /cvs/src/sys/arch/i386/include/vmparam.h,v >retrieving revision 1.56 >diff -u -r1.56 vmparam.h >--- sys/arch/i386/include/vmparam.h17 Apr 2018 15:50:05 - 1.56 >+++ sys/arch/i386/include/vmparam.h31 Jan 2021 09:41:00 - >@@ -46,7 +46,7 @@ > /* > * Virtual memory related constants, all in bytes > */ >-#define MAXTSIZ (128*1024*1024) /* max text size */ >+#define MAXTSIZ (256*1024*1024) /* max text size */ > #ifndef DFLDSIZ > #define DFLDSIZ (64*1024*1024) /* initial data size > limit */ > #endif > >
Re: execve -1 errno 12 Cannot allocate memory
Jonathan Gray wrote: >MAXTSIZ is 128 MB on i386 >see sys/arch/i386/include/vmparam.h Mark Kettenis wrote: >sys/arch/i386/include/vmparam.h has: >#define MAXTSIZ (128*1024*1024) /* max text size */ Thanks to both of you for the pointer! So what about the patch below? I've checked with a new kernel that it fixes the problem with chrome (even when using the default limits in /etc/login.conf). Philippe Index: sys/arch/i386/include/vmparam.h === RCS file: /cvs/src/sys/arch/i386/include/vmparam.h,v retrieving revision 1.56 diff -u -r1.56 vmparam.h --- sys/arch/i386/include/vmparam.h 17 Apr 2018 15:50:05 - 1.56 +++ sys/arch/i386/include/vmparam.h 31 Jan 2021 09:41:00 - @@ -46,7 +46,7 @@ /* * Virtual memory related constants, all in bytes */ -#defineMAXTSIZ (128*1024*1024) /* max text size */ +#defineMAXTSIZ (256*1024*1024) /* max text size */ #ifndef DFLDSIZ #defineDFLDSIZ (64*1024*1024) /* initial data size limit */ #endif
Re: execve -1 errno 12 Cannot allocate memory
> Date: Fri, 29 Jan 2021 09:48:42 -0500 > From: Philippe Meunier > > Philippe Meunier wrote: > >Is there some kind of limitation on the size of an ELF executable that can > >be executed on i386? I mean, in addition to the limits in /etc/login.conf? > > When using readelf(1) on the chrome executable from > chromium-81.0.4044.138.tgz from OpenBSD 6.7-release i386 packages, I get: > > Section Headers: > [Nr] Name TypeAddr OffSize ES Flg Lk Inf > Al > [...] > [15] .text PROGBITS0230d000 230d000 7bda799 00 AX 0 0 > 64 > > 7bda799 is 129869721 which is 123.8 MB. > > On the chrome executable from chromium-85.0.4183.121.tgz from OpenBSD > 6.8-release i386 packages, I get: > > Section Headers: > [Nr] Name TypeAddr OffSize ES Flg Lk Inf > Al > [...] > [15] .text PROGBITS02412c00 2411c00 83b048b 00 AX 0 0 > 64 > > 83b048b is 138085515 which is 131.7 MB. > > Is there somewhere a 128 MB limit for ELF sections on i386, or something > along those lines? sys/arch/i386/include/vmparam.h has: #define MAXTSIZ (128*1024*1024) /* max text size */
Re: execve -1 errno 12 Cannot allocate memory
On Fri, Jan 29, 2021 at 09:48:42AM -0500, Philippe Meunier wrote: > Philippe Meunier wrote: > >Is there some kind of limitation on the size of an ELF executable that can > >be executed on i386? I mean, in addition to the limits in /etc/login.conf? > > When using readelf(1) on the chrome executable from > chromium-81.0.4044.138.tgz from OpenBSD 6.7-release i386 packages, I get: > > Section Headers: > [Nr] Name TypeAddr OffSize ES Flg Lk Inf > Al > [...] > [15] .text PROGBITS0230d000 230d000 7bda799 00 AX 0 0 > 64 > > 7bda799 is 129869721 which is 123.8 MB. > > On the chrome executable from chromium-85.0.4183.121.tgz from OpenBSD > 6.8-release i386 packages, I get: > > Section Headers: > [Nr] Name TypeAddr OffSize ES Flg Lk Inf > Al > [...] > [15] .text PROGBITS02412c00 2411c00 83b048b 00 AX 0 0 > 64 > > 83b048b is 138085515 which is 131.7 MB. > > Is there somewhere a 128 MB limit for ELF sections on i386, or something > along those lines? > > Philippe MAXTSIZ is 128 MB on i386 see sys/arch/i386/include/vmparam.h
Re: execve -1 errno 12 Cannot allocate memory
Philippe Meunier wrote: >Is there some kind of limitation on the size of an ELF executable that can >be executed on i386? I mean, in addition to the limits in /etc/login.conf? When using readelf(1) on the chrome executable from chromium-81.0.4044.138.tgz from OpenBSD 6.7-release i386 packages, I get: Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al [...] [15] .text PROGBITS0230d000 230d000 7bda799 00 AX 0 0 64 7bda799 is 129869721 which is 123.8 MB. On the chrome executable from chromium-85.0.4183.121.tgz from OpenBSD 6.8-release i386 packages, I get: Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al [...] [15] .text PROGBITS02412c00 2411c00 83b048b 00 AX 0 0 64 83b048b is 138085515 which is 131.7 MB. Is there somewhere a 128 MB limit for ELF sections on i386, or something along those lines? Philippe
