Date: Fri, 5 Feb 1999 14:31:54 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: John Polstra <jdp@polstra.com> Cc: committers@FreeBSD.ORG Subject: Re: cvs commit: src/sys/vm vm_unix.c Message-ID: <199902052231.OAA99829@apollo.backplane.com> References: <XFMail.990205140511.jdp@polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:But this is architecture-independent code, so it must not rely on
:that. On some architectures, execute permission really is distinct
:from read permission. Obviously on architectures where execute
:permission is ignored, your change is a no-op and we have nothing to
:discuss. Therefore in the following I am going to speak to the case
:where execute permission matters.
:
:And in that case, the data segment must be VM_PROT_ALL for a very
:important reason that I hadn't thought of originally -- namely, lazy
:binding of function calls in dynamically linked programs. This is
:implemented by executing code that is in the GOT (global offset
:table), which is in the data segment because it must be writable.
:Since code is executed there, it must be executable as well.
This has nothing to do with the commit. ELF segments include flags
for r, w, x. This commit does not effect ELF segments, nor would it
be appropriate to override the flags stored in elf segments. This
commit effects only obreak. obreak is only used by malloc.
:> Also, dynamic loaders and ( I expect ) JIT compilers use mmap()
:> to allocate space.
:
:I checked the kaffe sources, and by default it doesn't use mmap().
:You can force it to do so with a configure option, but our FreeBSD
:port doesn't do that currently. Yet JIT works in kaffe under FreeBSD.
:...
:> cache.
:
:Kaffe must have found some way to solve that problem.
:...
:> Plus, a JIT compiler would also use mprotect().
:
:Kaffe doesn't use mprotect().
If Kaffe is using malloc() and it reallocates the space later or modifies
the space later after having executed something in it, Kaffe is broken.
It sounds to me like Kaffe needs to be fixed. Maybe they developed Kaffe
on an IA32 platform where execute perms don't matter? Even so, it would
be total luck if they were actually rewriting a data space in which they
had previous executed something for the L1 cache to not get corrupted.
-Matt
Matthew Dillon
<dillon@backplane.com>
:John
:---
: John Polstra jdp@polstra.com
: John D. Polstra & Co., Inc. Seattle, Washington USA
: "Nobody ever went broke underestimating the taste of the American public."
: -- H. L. Mencken
:
:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902052231.OAA99829>