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
execve -1 errno 12 Cannot allocate memory
Hello, 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? Here's why I'm asking: $ uname -a OpenBSD t43.my.domain 6.8 GENERIC#4 i386 $ cat /etc/login.conf [...] default:\ :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/local/sbin:\ :umask=022:\ :datasize-max=infinity:\ :datasize-cur=infinity:\ :memoryuse-max=infinity:\ :memoryuse-cur=infinity:\ :memorylocked-max=infinity:\ :memorylocked-cur=infinity:\ :vmemoryuse-max=infinity:\ :vmemoryuse-cur=infinity:\ :maxproc-max=256:\ :maxproc-cur=128:\ :openfiles-max=1024:\ :openfiles-cur=512:\ :stacksize-max=infinity:\ :stacksize-cur=infinity:\ :localcipher=blowfish,a:\ :tc=auth-defaults:\ :tc=auth-ftp-defaults: [...] (/etc/login.conf is that way just for testing purposes...) $ ulimit -a time(cpu-seconds)unlimited file(blocks) unlimited coredump(blocks) unlimited data(kbytes) 3145728 stack(kbytes)32768 lockedmem(kbytes)unlimited memory(kbytes) unlimited nofiles(descriptors) 512 processes128 $ /usr/local/chrome/chrome /bin/ksh: /usr/local/chrome/chrome: Cannot allocate memory $ ktrace -d -i /usr/local/chrome/chrome ktrace: exec of '/usr/local/chrome/chrome' failed: Cannot allocate memory $ kdump -X 23578 ktrace RET ktrace 0 23578 ktrace CALL execve(0xcf7ebfc1,0xcf7ebf10,0xcf7ebf18) 23578 ktrace NAMI "/usr/local/chrome/chrome" 23578 ktrace RET execve -1 errno 12 Cannot allocate memory 23578 ktrace CALL mprotect(0x58b08000,0x1000,0x3) 23578 ktrace RET mprotect 0 23578 ktrace CALL mprotect(0x58b08000,0x1000,0x1) 23578 ktrace RET mprotect 0 23578 ktrace CALL write(2,0xcf7eb818,0x8) 23578 ktrace GIO fd 2 wrote 8 bytes : 6b 74 72 61 63 65 3a 20 ktrace: 23578 ktrace RET write 8 23578 ktrace CALL write(2,0xcf7eb838,0x29) 23578 ktrace GIO fd 2 wrote 41 bytes : 65 78 65 63 20 6f 66 20 27 2f 75 73 72 2f 6c 6f exec of '/usr/lo 0010: 63 61 6c 2f 63 68 72 6f 6d 65 2f 63 68 72 6f 6d cal/chrome/chrom 0020: 65 27 20 66 61 69 6c 65 64 e' failed 23578 ktrace RET write 41/0x29 23578 ktrace CALL write(2,0xcf7eb820,0x2) 23578 ktrace GIO fd 2 wrote 2 bytes : 3a 20: 23578 ktrace RET write 2 23578 ktrace CALL write(2,0xcf7eb818,0x17) 23578 ktrace GIO fd 2 wrote 23 bytes : 43 61 6e 6e 6f 74 20 61 6c 6c 6f 63 61 74 65 20 Cannot allocate 0010: 6d 65 6d 6f 72 79 0a memory. 23578 ktrace RET write 23/0x17 23578 ktrace CALL mprotect(0x58b08000,0x1000,0x3) 23578 ktrace RET mprotect 0 23578 ktrace CALL mprotect(0x58b08000,0x1000,0x1) 23578 ktrace RET mprotect 0 23578 ktrace CALL mprotect(0x58b08000,0x1000,0x3) 23578 ktrace RET mprotect 0 23578 ktrace CALL mprotect(0x58b08000,0x1000,0x1) 23578 ktrace RET mprotect 0 23578 ktrace CALL munmap(0x58b08000,0x1000) 23578 ktrace RET munmap 0 23578 ktrace CALL exit(1) $ file /usr/local/chrome/chrome /usr/local/chrome/chrome: ELF 32-bit LSB shared object, Intel 80386, version 1 $ ls -l /usr/local/chrome/chrome -rwxr-xr-x 1 root bin 179649140 Oct 2 12:45 /usr/local/chrome/chrome It looks like execve simply refuses to execute that file but I cannot find which limit is being hit. The next biggest executable I can find on my system is /usr/bin/cc which is 62177052 bytes on the hard disk, and I have no problem executing it. This is using OpenBSD 6.8-release (with syspatches applied; dmesg below). I just upgraded from 6.7-release which is when I found out about this problem with chrome. On 6.7 I had datasize-max, datasize-cur, and memoryuse set to 1024M in /etc/login.conf and never had any problem using chrome. Any idea what the problem might be? Best, Philippe OpenBSD 6.8 (GENERIC) #4: Mon Jan 11 10:34:49 MST 2021 r...@syspatch-68-i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC real mem = 1063600128 (1014MB) avail mem = 1027911680 (980MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: date 05/29/07, BIOS32 rev. 0 @ 0xfd740, SMBIOS rev. 2.33 @ 0xe0010 (64 entries) bios0: vendor IBM version "70ET69WW (1.29 )" date 05/29/2007 bios0: IBM 1875E5U acpi0 at bios0: ACPI 3.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG BOOT acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB3(S3) USB7(S3) AC9M(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0