Re: Linux emulation on FreeBSD AMD64

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:%dn",
(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.

_______________________________________________
freebsd-emulationfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-emu
lation
To unsubscribe, send any mail to
"freebsd-emulation-unsubscribefreebsd.org"