From: Godmar Back (gback@cs.utah.edu)
Date: Sun Feb 07 1999 - 22:22:17 EST
Matthew, Archie,
You seem to be discussing an older version of kaffe.
What kaffe on FreeBSD does is to expect to sbrk a region of memory,
write instructions into it and execute them. Is this illegal?
So, does the proposed patch turn off executable permission in the
data segment? This would seem silly, but it wouldn't be a show stopper
for us: we can always mmap memory and use mprotect to give it execute
permissions, can't we?
Maybe I don't understand what this is about.
- Godmar
>
> The claim here is that if kaffe executes code that's in
> a malloc()'d region, then it's broken. I don't completely
> understand the argument but FWIW..
>
> I've requested a POSIX reference etc. for this claim.
>
> -Archie
>
>
> ----- Forwarded message from Matthew Dillon -----
>
> >From owner-cvs-committers@FreeBSD.ORG Fri Feb 5 14:36:01 1999
> Date: Fri, 5 Feb 1999 14:31:54 -0800 (PST)
> From: Matthew Dillon <dillon@apollo.backplane.com>
> Message-Id: <199902052231.OAA99829@apollo.backplane.com>
> To: John Polstra <jdp@polstra.com>
> Cc: committers@FreeBSD.ORG
> Subject: Re: cvs commit: src/sys/vm vm_unix.c
> References: <XFMail.990205140511.jdp@polstra.com>
> Sender: owner-cvs-committers@FreeBSD.ORG
> Precedence: bulk
> X-Loop: FreeBSD.ORG
>
> :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
> :
> :
>
>
> ----- End of forwarded message from Matthew Dillon -----
> ___________________________________________________________________________
> Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
>
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:58:00 EDT