Date: Fri, 05 Feb 1999 14:45:44 -0800 (PST) From: John Polstra <jdp@polstra.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: committers@FreeBSD.ORG Subject: Re: cvs commit: src/sys/vm vm_unix.c Message-ID: <XFMail.990205144544.jdp@polstra.com> In-Reply-To: <199902052231.OAA99829@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.990205144544.jdp>