Skip site navigation (1)Skip section navigation (2) 
Date:      Thu, 24 Oct 2013 01:37:51 -0500
From:      Kevin Day <toasty@dragondata.com>
To:        d@delphij.net, Xin Li <delphij@delphij.net>
Cc:        Puppet Master <pmaster@mindslayer.net>, "freebsd-hackers@freebsd.org Hackers" <freebsd-hackers@freebsd.org>
Subject:   Re: FoxPro on FreeBSD
Message-ID:  <8A799DDB-3D5C-4418-B064-A2B7821EE0F2@dragondata.com>
In-Reply-To: <5268B62B.3000104@delphij.net>
References:  <52687ED8.6080309@mindslayer.net> <9B89077C-6BE7-49F1-9F22-19FAD9F6C3ED@dragondata.com> <5268B62B.3000104@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help 

[-- Attachment #1 --]

On Oct 24, 2013, at 12:54 AM, Xin Li <delphij@delphij.net> wrote:

> Signed PGP part
> On 10/23/13, 8:32 PM, Kevin Day wrote:
> > I did some debugging, and watched how the process was getting
> > launched, and I've managed to get it to load!
> > 
> > The problem was that COFF files expect to be mapped into memory at
> > address 0, something that processes are no longer allowed to do.
> > 
> > Run "sysctl security.bsd.map_at_zero=1  or add
> > security.bsd.map_at_zero=1 to /etc/sysctl.conf and you should
> > have it working. We probably should either make an exception for
> > COFF files to bypass this the sysctl restriction, or at least print
> > a more helpful error than just letting the process segfault because
> > it didnt get mapped where it was supposed to go.
> 
> Wow, this is impressive find, indeed!  Do they need to do the map at
> startup only, or do they want to explicitly map something at address 0
> during runtime?

Its the COFF loader in sys/i386/ibcs2 thats attempting to do this, with some debug printing enabled on the ibcs2 module, you can see the layout of the binary:

i = 0, s_name = .text, s_vaddr = 000000d0, s_scnptr = 208 s_size = 1f9260
i = 1, s_name = .data, s_vaddr = 00400330, s_scnptr = 2069296 s_size = 10598
i = 2, s_name = .bss, s_vaddr = 004108c8, s_scnptr = 0 s_size = 1ebb0
i = 3, s_name = .comment, s_vaddr = 00000000, s_scnptr = 2136264 s_size = feb4

which maps to these calls:

vm_mmap(&vmspace->vm_map, &0x00000000, 0x1fa000, 0x5, VM_PROT_ALL, MAP_PRIVATE | MAP_FIXED, OBJT_VNODE, vp, 0x0)
vm_mmap(&vmspace->vm_map, &0x00400000, 0x10000, 0x7, VM_PROT_ALL, MAP_PRIVATE | MAP_FIXED, OBJT_VNODE, vp, 0x1f9000)
vm_map_find(&vmspace->vm_map, NULL, 0, &0x00410000,0x20000, VMFS_NO_SPACE, VM_PROT_ALL, VM_PROT_ALL, 0)
vm_map_find(&vmspace->vm_map, NULL, 0, &0x430000, PAGE_SIZE, FALSE, VM_PROT_ALL, VM_PROT_ALL, 0)

Nothing is returning any errors, but the .text session isnt getting mapped to the desired location (0x0). If map_at_zero is set to 0, the processs vm_map has min_offset set to PAGE_SIZE instead of 0. 

Whats actually happening is pretty subtle. if MAP_FIXED is set, vm_mmap() uses vm_map_fixed() to create the mapping. Inside vm_map_fixed(), it uses vm_map_insert() which would properly error out that this mapping is impossible (we want 0x0, but the processs vm_map.min_offset is 0x1000), but vm_map_fixed() calls VM_MAP_RANGE_CHECK first:

        VM_MAP_RANGE_CHECK(map, start, end);
        (void) vm_map_delete(map, start, end);
        result = vm_map_insert(map, object, offset, start, end, prot,

VM_MAP_RANGE_CHECK does:

                if (start < vm_map_min(map))            \
                        start = vm_map_min(map);        \

which looks like the wrong thing to do here. vm_mmap() thinks its requesting 0x0 through 0x1fa000, but now the request just silently got changed to 0x1000 through 0x1fa000.

So what the ibcs2 module thinks .text is being loaded at 0, ends up being loaded at 0x1000, and is 0x1000 bytes too small.  It then jumps to the wrong starting address, and the process crashes. 

Also to clarify my original posting, COFF itself isnt the issue here, just that this specific binary wants its .text section to begin at a virtual address below 0x1000. 

 Kevin



[-- Attachment #2 --]
0	*H
010	+0	*H
/00Šq_Mtq40
	*H
0{10	UGB10UGreater Manchester10USalford10U
Comodo CA Limited1!0UAAA Certificate Services0
040101000000Z
281231235959Z010	UUS10	UUT10USalt Lake City10U
The USERTRUST Network1!0Uhttp://www.usertrust.com1604U-UTN-USERFirst-Client Authentication and Email0"0
	*H
0
9}A;bF7`u9eJGHjM5BI/|1Nd.)բdąQ5yNh{zɤ2O0nFxoY^/m/묡j.g5yiF͠v:z'[=s"HaLi.1 ,׉CZqYں
gT:
wetbh~GeMW(t40b0,'0#0U#0
#>)00Ug}ĝ&pKPH|=n}0U0U00U%0++0U 
00U 0{Ut0r08642http://crl.comodoca.com/AAACertificateServices.crl06420http://crl.comodo.net/AAACertificateServices.crl0	`HB0
	*H
<~	v9<Oૄ]Te;m|7,%T_!7OTklE`-QLf<J?VvÂOlatG@We"'gOWdZٍ/i)J /LQFĊ7N 	1hǞċ~2hD*Q`Mt:C29V:RAC3'9N&9≸])&A곛wuʵeJc>D^s00mOj3""2zq0
	*H
010	UUS10	UUT10USalt Lake City10U
The USERTRUST Network1!0Uhttp://www.usertrust.com1604U-UTN-USERFirst-Client Authentication and Email0
110428000000Z
200530104838Z010	UGB10UGreater Manchester10USalford10U
COMODO CA Limited1907U0COMODO Client Authentication and Secure Email CA0"0
	*H
0
[KW^/@ȣSX_fe2N2}UxLUB'qi2@'Vbqi c^`ʢAjHmeC*.+c8w߱ڂ2jgo \5Tq
7
PSlY1	LR@[HhJ$:q_㬿;%qh=XF<hmz!W42~JRrd&N`ohQcB}"cөΞD\[5K0G0U#0g}ĝ&pKPH|=n}0UzNt[xcd'/[y{0U0U00U 
00U 0XUQ0O0MKIGhttp://crl.usertrust.com/UTN-USERFirst-ClientAuthenticationandEmail.crl0t+h0f0=+01http://crt.usertrust.com/UTNAddTrustClient_CA.crt0%+0http://ocsp.usertrust.com0
	*H
־xWUm3DRB
JAIZҭsn>&|L0(B<%>
u=9fѡMo(ltZڱuz/yVtCr`9 G:eH<=%`I?C
3_н`j;:<I3B)93i.EMiڀ=]|Gm]W0KID~y83:]&XaU!ՙC@B0Ұun0,07Ca`)̀0
	*H
010	UGB10UGreater Manchester10USalford10U
COMODO CA Limited1907U0COMODO Client Authentication and Secure Email CA0
130616000000Z
140616235959Z0&1$0"	*H
	toasty@dragondata.com0"0
	*H
0
-`ghX/9+ˈe`?l/E^~T׀/q+5SzSrIuert`:"k_s{&
0T
kˢbWieK;2LX8w.YpI!3|M19Y2vGrAҽ5yX^0
@JbfBќ`
TZO$mx1}LN0Rw00U#0zNt[xcd'/[y{0Up=#P}L:w񹭸qX0U0U00 U%0++10	`HB 0FU ?0=0;+10+0)+https://secure.comodo.net/CPS0WUP0N0LJHFhttp://crl.comodoca.com/COMODOClientAuthenticationandSecureEmailCA.crl0+|0z0R+0Fhttp://crt.comodoca.com/COMODOClientAuthenticationandSecureEmailCA.crt0$+0http://ocsp.comodoca.com0 U0toasty@dragondata.com0
	*H
iqk4Dlse-8 uy:1:ߩ(w}tRƼHyT΀	4Y=GeKr:/ܜ1n*tښ6ڇڿ3D.~fm5Q(Yœ!@'=vn5i뷹K^#MF0=~<hGgһKR}KrBai1cvqm3RNSeEx\G4
=FwɺL4rIU100010	UGB10UGreater Manchester10USalford10U
COMODO CA Limited1907U0COMODO Client Authentication and Secure Email CA7Ca`)̀0	+0	*H
	1	*H
0	*H
	1
131024063752Z0#	*H
	1J}e0HHE'ZdU0	+710010	UGB10UGreater Manchester10USalford10U
COMODO CA Limited1907U0COMODO Client Authentication and Secure Email CA7Ca`)̀0*H
	1010	UGB10UGreater Manchester10USalford10U
COMODO CA Limited1907U0COMODO Client Authentication and Secure Email CA7Ca`)̀0
	*H
K>Y}G
[<`tӏ]}%OlLh,!Pf_ǖcWٕh]a(ȫjܮXgg#>*+7O/Wu(>)	;W~!jq^Gj6Cmk]o=ۃ%dERQ˾n(Y	 A@W^7M̔}rF@x6J0YG֙i%נda($-

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8A799DDB-3D5C-4418-B064-A2B7821EE0F2>