Linux emulation on FreeBSD AMD64

[Valery V.Chikalov]

Valery V.Chikalov wrote:
> Martin Cracauer wrote:
>> Valery V.Chikalov wrote on Thu, Nov 01, 2007 at 10:32:16AM +0200:
>>> Martin Cracauer wrote:
>>>> Valery V.Chikalov wrote on Sun, Oct 28, 2007 at 12:08:38AM +0300:
>>>>> Oct 27 19:42:59 tiger kernel: mprotect addr:2a27d000, return 0
>>>>> Oct 27 19:42:59 tiger kernel: mprotect addr:2a7c1000, return 0
>>>>> Oct 27 19:42:59 tiger kernel: mprotect addr:2a7cd000, return 0
>>>>> Oct 27 19:42:59 tiger kernel: mprotect addr:2a7e2000, return 0
>>>>> Oct 27 19:42:59 tiger kernel: mprotect addr:2a7ef000, return 0
>>>>> Oct 27 19:43:09 tiger kernel: mprotect addr:55c00000, return 13
>>>>> Oct 27 19:43:09 tiger kernel: mprotect addr:55c81000, return 13
>>>> You need to check whether these is anything mapped there in the first
>>>> place and what the permissions are.
>>>>
>>>> This is probably best done by changing your debugging code in the
>>>> Linuxulator to print amessage, then sleep for 10 seconds giving you
>>>> time to copy the memory map to a safe place, then look up what the
>>>> mapping at the position was.
>>>>
>>>> Martin
>>> Hi, Martin.
>>>
>>> Thank you for the hint.
>>> But I'm not sure that I understanding you right.
>>> I'm not a kernel hacker, just C-programmer with ability to read 
>>> documentation. :-)
>>> Do the "memory map" about you told is some C-struct I can deal with 
>>> and which can be accessed by some system call, or that task ("copy 
>>> the memory map") can be achieved by some userland utility like "ipcs" 
>>> or "vmstat -m".
>>
>> No, you need the contents of /proc/<pid>/map
>> and
>> /compat/linux/proc/<pid>/maps
>>
> 
> Hi, Martin.
> 
> Thank you for help.
> You have reminded me about the /proc, which I have stopped using a long 
> time ago as "deprecated" in favor of sysctl. In this case it is really 
> useful.
> 
>> This is why you hack up the kernel to wait a while, before the syscall
>> is actually executed you want the time to grab both these files for
>> the process and save them somewhere (cp /proc... /tmp/ is sufficient).
>>
> 
> I can use a little simpler method as I have perfectly running exemplar 
> of Oracle on another computer on FreeBSD in i386 mode.
> 
> So in first place I'm getting:
> 
> oerr ORA 27122
> 27122, 00000, "unable to protect memory"
> // *Cause: mprotect() call failed
> 
> After the diagnostic patch proposed by rdivacky@ to linux_machdep.c
> 
> +#if 0
>         if (bsd_args.prot & (PROT_READ | PROT_WRITE | PROT_EXEC))
>                 bsd_args.prot |= PROT_READ | PROT_EXEC;
> +#endif
> 
> I got started oracle and see expected difference between
> /compat/linux/proc/<PID>/maps:
> (i386)
> 2a846000-2a849000 rwxp 00003000 00:00 0
> 50000000-60000000 rwxp 10083000 00:00 0
> 60000000-60001000 r-xp 10083000 00:00 0
> 60001000-60081000 rwxp 10083000 00:00 0
> 60081000-60082000 r-xp 10083000 00:00 0
> 60082000-60083000 rwxp 10083000 00:00 0
> bf7e0000-bf800000 rwxp 00020000 00:00 0
> (AMD64)
> 2a7c3000-2a804000 rwxp 00041000 00:00 0
> 50000000-55c00000 rw-p 05c83000 00:00 0
> 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
> fffdf000-fffff000 rwxp 00020000 00:00 0
> 
> Note absence of the execution bit.
> 
> And then after some time Oracle coredumps
> 
> quotation from rdivacky@ mail:
> 
>  >I think its quite obvious...  oracle expects some memory is executable
>  >and tries to execute something in it but freebsd has non-exec bit set
>  >on that memory hence core dump...
> 
> I tend to agree, but see below...
> 
>> I suspect the difference between Linux and FreeBSD here is what kind
> 
> My point is that we must look for the difference not between Linux and 
> FreeBSD, but between FreeBSD(i386) and FreeBSD(AMD64), or between Linux 
> and Linux emulation on FreeBSD *AMD64* and any explanations of this 
> artifact must contain an AMD64 specific.
> 
>  > of existing mapping you are allowed to change in permissions.  Should
>  > be reasonably easy to fix once we know both side, what permissions you
>  > had before (from the maps) and where you want to go (from the
>  > syscall arguments).  Might be more hairy if some special kind of
>  > memory is involved but we'll see.

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

So, the question is what is changed in AMD64 arch with respect to SYSV 
shared memory?
Why vm_map_protect from /sys/vm/vm_mmap.c returns 
KERN_PROTECTION_FAILURE in attempts to change protection of such type of 
memory?

Args are:
vm_map_protect:addr:1438646272, addr+size:1438650368, prot:5


Thanks.
Valery.

> 
>>
>> Martin
> 
> 
> 
> _______________________________________________
> freebsd-emulation at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-emulation
> To unsubscribe, send any mail to 
> "freebsd-emulation-unsubscribe at freebsd.org"