Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 5 Nov 2007 15:01:06 +0200
From:      Kostik Belousov <kostikbel@gmail.com>
To:        "Valery V.Chikalov" <valera@chikalov.dp.ua>
Cc:        freebsd-emulation@freebsd.org
Subject:   Re: Linux emulation on FreeBSD AMD64
Message-ID:  <20071105130106.GQ37471@deviant.kiev.zoral.com.ua>
In-Reply-To: <472F0F82.8070002@chikalov.dp.ua>
References:  <472B0454.9040408@chikalov.dp.ua> <472B9CD1.1010607@chikalov.dp.ua> <472DAF60.9040008@chikalov.dp.ua> <20071104122023.GA5528@freebsd.org> <472DC7C3.3090105@chikalov.dp.ua> <20071104133518.GA7275@freebsd.org> <20071104171423.GL37471@deviant.kiev.zoral.com.ua> <472E067A.5050601@chikalov.dp.ua> <20071105095053.GP37471@deviant.kiev.zoral.com.ua> <472F0F82.8070002@chikalov.dp.ua>

index | next in thread | previous in thread | raw e-mail

[-- Attachment #1 --]
On Mon, Nov 05, 2007 at 02:41:38PM +0200, Valery V.Chikalov wrote:
> Kostik Belousov wrote:
> >On Sun, Nov 04, 2007 at 07:50:50PM +0200, Valery V.Chikalov wrote:
> >>Kostik Belousov wrote:
> >>[...]
> >>
> >>Index: vmparam.h
> >>===================================================================
> >>RCS file: /home/ncvs/src/sys/amd64/include/vmparam.h,v
> >>retrieving revision 1.49
> >>diff -u -r1.49 vmparam.h
> >>--- vmparam.h	25 Sep 2007 06:25:04 -0000	1.49
> >>+++ vmparam.h	4 Nov 2007 14:43:39 -0000
> >>@@ -45,6 +45,10 @@
> >> #ifndef _MACHINE_VMPARAM_H_
> >> #define	_MACHINE_VMPARAM_H_ 1
> >>
> >>+#ifdef	COMPAT_IA32
> >>+#define VM_PROT_READ_IS_EXEC    /* if you can read -- then you can exec 
> >>*/
> >>+#endif
> >>+
> >No, this is wrong fix. It changes the ABI for freebsd binaries, and does
> >this not only for SysV shm, but for any readable mapping.
> >
> >Instead, the following things shall be made:
> 
> Thanks, will try to do it this way.
> 
> But, just for curiosity and for my education.
> 
> My point from teh beginning was: we must find differences between linux 
> emulations in __i386__ and __amd64__(dont take it too literally, I dont 
> mean diff /sys/i386/xxx /sys/amd64/xxx :-)), because oracle is running 
> perfectly in __i386__ mode and failed to run in __amd64__.
> 
> On the first glance such difference was found: VM_PROT_READ_IS_EXEC is 
> defined in /sys/[i386|arm]/include/vmparam.h but not in 
> /sys/amd64/include/vmparam.h.
AMD64 (and, in fact, some i386, when running in PAE mode) has so-called
execution-disable bit in the page protection attributes. The patch would
make the PROT_READ == PROT_READ | PROT_EXEC unconditionally.

> 
> But:
> 1) you claim that this is wrong.
>    So, why? Why this is right for i386|arm and wrong for amd64.
> 
> > 1. linux_shmat() shall call kern_shmat().
> > 2. kern_shmat() shall take the flag that would force the read mapping
> >    to be also executable.
> > 3. this flag shall be set when kern_shmat() is called from linux_shmat(),
> >    and not set when called from shmat().
> 
> Why this is not applicable to i386 mode?
Good question, I did  not looked into the details of handling PROT_EXEC
on i386 when nx bit is supported. FreeBSD definitely ignores PT_GNU_STACK
for non-executable stacks, I am not sure what could break with this on i386.

[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)

iD8DBQFHLxQRC3+MBN1Mb4gRAqTMAKCroUU1OC9jv1GFVIsUnmOYTEvHhwCgwtOn
jx+2sD5eRBGzKpTHTklOTsg=
=LITX
-----END PGP SIGNATURE-----
help

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071105130106.GQ37471>