From owner-cvs-all Fri Feb 5 14:45:52 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA14840 for cvs-all-outgoing; Fri, 5 Feb 1999 14:45:52 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA14828 for ; Fri, 5 Feb 1999 14:45:45 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id OAA02709; Fri, 5 Feb 1999 14:45:44 -0800 (PST) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.1/8.9.1) id OAA31362; Fri, 5 Feb 1999 14:45:44 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199902052231.OAA99829@apollo.backplane.com> Date: Fri, 05 Feb 1999 14:45:44 -0800 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: Matthew Dillon Subject: Re: cvs commit: src/sys/vm vm_unix.c Cc: committers@FreeBSD.ORG Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk Matthew Dillon wrote: [jdp] >: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, Your commit message talked about how the ELF loader sets the permissions on BSS, and the fact that they don't match what obreak does. So it must have something to do with the BSS segment at least. Though the GOT is in the data (not BSS) segment, so maybe that doesn't matter. > nor would it be appropriate to override the flags stored in elf > segments. I am saying it may be _necessary_ to override the flags of the data segment at least, if we ever go to an architecture where execute permission matters. It depends on a lot of things though. E.g., a different lazy binding scheme might be used, or the linker might set the X bit in the segment itself. It's hypothetical at this point, but in any event we can't rely on "knowing" that read permission == execute permission. >: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. Since kaffe has its own garbage collector, it probably doesn't use malloc. I suspect that it uses sbrk. But I already deleted the sources and don't feel like dragging them out again. > It sounds to me like Kaffe needs to be fixed. Maybe they > developed Kaffe on an IA32 platform where execute perms don't > matter? Probably. > 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. I didn't dig into it far enough to see what they did about the cache. I'm reasonably sure they didn't just ignore the issue. They would have run into it by now if they had. 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