From owner-cvs-all Fri Feb 5 14:31:59 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA13228 for cvs-all-outgoing; Fri, 5 Feb 1999 14:31:59 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA13222 for ; Fri, 5 Feb 1999 14:31:57 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id OAA99829; Fri, 5 Feb 1999 14:31:54 -0800 (PST) (envelope-from dillon) Date: Fri, 5 Feb 1999 14:31:54 -0800 (PST) From: Matthew Dillon Message-Id: <199902052231.OAA99829@apollo.backplane.com> To: John Polstra Cc: committers@FreeBSD.ORG Subject: Re: cvs commit: src/sys/vm vm_unix.c References: Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk :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 :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