From owner-freebsd-emulation@FreeBSD.ORG Sun Nov 4 11:41:47 2007 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9495416A41A; Sun, 4 Nov 2007 11:41:46 +0000 (UTC) (envelope-from valera@chikalov.dp.ua) Received: from halik.com.ua (halik.com.ua [193.178.146.121]) by mx1.freebsd.org (Postfix) with ESMTP id 2040013C48D; Sun, 4 Nov 2007 11:41:45 +0000 (UTC) (envelope-from valera@chikalov.dp.ua) Received: from tiger.novakom.dp.ua (unknown [213.227.219.58]) by halik.com.ua (Postfix) with ESMTP id 40D345C032; Sun, 4 Nov 2007 13:41:26 +0200 (EET) Message-ID: <472DAF60.9040008@chikalov.dp.ua> Date: Sun, 04 Nov 2007 13:39:12 +0200 From: "Valery V.Chikalov" User-Agent: Thunderbird 2.0.0.6 (X11/20070814) MIME-Version: 1.0 To: Martin Cracauer References: <4721AB07.20708@novakom.com.ua> <4723A8D6.6020002@chikalov.dp.ua> <20071031180639.GA93259@cons.org> <47298F10.4050301@chikalov.dp.ua> <20071101152550.GA10868@cons.org> <472B0454.9040408@chikalov.dp.ua> <472B9CD1.1010607@chikalov.dp.ua> In-Reply-To: <472B9CD1.1010607@chikalov.dp.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-emulation@freebsd.org Subject: Re: Linux emulation on FreeBSD AMD64 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2007 11:41:47 -0000 Valery V.Chikalov wrote: [...] > Ok, I have fond what is so special with this memory. Oracle uses SYSV > shared memory, and comparing output from "ipcs -mb" and > /compat/linux/proc//maps it's became clear that that suspiciously > looking too high addresses of memory chunks with missed execution bit > are SYSV shared memory areas. > > > 50000000-55c00000 rw-p 05c83000 00:00 0 - this is main chunk which > can be seen in output of "show sga" sqlplus command > > > 55c00000-55c01000 r--p 05c83000 00:00 0 > > 55c01000-55c81000 rw-p 05c83000 00:00 0 > > 55c81000-55c82000 r--p 05c83000 00:00 0 > > 55c82000-55c83000 rw-p 05c83000 00:00 0 - this are adjusted to the > end small (4096) pieces > I made a step a little further. It's now clear that we are interested in memory only from address 0x50000000 (this is also confirming by oracle manual). So now we can narrow the area of mprotect monitoring: if (uap->addr >= 0x50000000) printf("mprotect: addr:%lx, len:%d, prot:%d, bsdprot:%d, ret:%d\n", (unsigned long)uap->addr, uap->len, uap->prot, bsd_args.prot, ret); OTOH I have hacked the /sys/vm/vm_map.c by commenting out the next lines: /* if ((new_prot & current->max_protection) != new_prot) { vm_map_unlock(map); return (KERN_PROTECTION_FAILURE); } */ Leave out the reason why it failing for now. as a result we are geting: Nov 4 12:40:14 tiger kernel: mprotect: addr:55c00000, len:4096, prot:1, bsdprot:5, ret:0 Nov 4 12:40:14 tiger kernel: mprotect: addr:55c81000, len:4096, prot:1, bsdprot:5, ret:0 this two lines repeating 9 times. Lets note presents only two memory addresses from 5 shown above. and a /compat/linux/proc//maps looks like: 50000000-55c00000 rw-p 05c83000 00:00 0 55c00000-55c01000 r-xp 05c83000 00:00 0 55c01000-55c81000 rw-p 05c83000 00:00 0 55c81000-55c82000 r-xp 05c83000 00:00 0 55c82000-55c83000 rw-p 05c83000 00:00 0 So, now all from mprotect calls executing with success, but 3 memory areas still missing execute bit and oracle as effect coredumps. In linux_mmap_common there is the same trick with "prot" argument like in linux_mprotect: /* * PROT_READ, PROT_WRITE, or PROT_EXEC implies PROT_READ and PROT_EXEC * on Linux/i386. We do this to ensure maximum compatibility. * Linux/ia64 does the same in i386 emulation mode. */ bsd_args.prot = linux_args->prot; if (bsd_args.prot & (PROT_READ | PROT_WRITE | PROT_EXEC)) bsd_args.prot |= PROT_READ | PROT_EXEC; but turning on the debug for the linux_mmap_common gives no result. So linux_mmap_common not taking part in creating and changing rights of others 3 memory areas. So the question is what is the origin of this memory chunks? By calling which function there was created or managed? Maybe in this function there is place for the same hack with linux_args->prot to bsd_args.prot mapping? Thanks. Valery.