Linux emulation on FreeBSD AMD64

[Valery V.Chikalov]

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/<PID>/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/<PID>/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.