I'm tracking down why my Reva Forth doesn't build on my "hostmysite" web-server.

It seems they are running Redhat Enterprise AS 4, which has various security enhancements. Among them, it apparently takes advantage of the NX CPU bit.

Does anyone know how I can defeat this protection for my application? Is that even possible, or do I have to beg the sysadmin to let my program run?

Does Linux provides an equivalent for VirtualProtect of Windows? If it does then you can set execute permission for the allocated pages (which should disable the NX bit).

I tried using "mprotect" to set all the areas to read/write/execute, but it didn't have the effect I need.

On the 3.x line of Redhat Enterprise Server, using "setarch i386 <binary>" would disable the exec-shield for that binary. I'm not sure if this works on 4.x though.

Nice try - but "setarch" doesn't exist on this server.

ronware, do you execute from memory from malloc() (or whatever equivalent you're using)? Or even, shudder, from the stack?

If that's the problem, you might want to try changing the memory allocation to mmap(), where you can specify PROT_READ|PROT_WRITE|PROT_EXEC...

The program is written in FASM, it doesn't even do memory management. Code is not executed off the stack, but it does use self-modifying code to some extent

Just to clear up something from your original post - do you mean "Doesn't build" or "Doesn't run"?

I can see your '.flat' section is writable/executable (hm, why not readable as well?), so perhaps the linux distro takes it upon itself to enforce read-only for code sections?

Or perhaps the syscall interface has changed? (seems unlikely, but still needs to be considered)

And obviously you *do* some memory management, at least I see references to malloc and friends, so the question re-appears: do you ever execute from dynamically allocated memory?

To clarify: it doesn't build. The build is in two stages: 1) build "revacore" and 2) build "reva" using "revacore".

The first step is fine. "revacore" even runs, and works "ok" until you try to create a new word (which the build of "reva" does almost exclusively). To see what I mean, do:

bin/revacore
234 4 (.r) type

You should see " 234" print out. This indicates that the interpreter portion works fine. Now type:

: a ;
a

Trying to execute the new "a" word will cause a SIGSEGV. So until I spend some serious time trying to debug this, I will just be guessing.

Yes, I thought that perhaps they are enforcing read-only code, in which case I'm probably out of luck because changing that would be a major rewrite (e.g. only compiling into allocated memory, then changing the permissions to 'execute', etc.). Trying "mprotect" didn't help, though perhaps I invoked it incorrectly.

OK, you're right - I do actually use "malloc" in the "revacore" - but not for executing, just for read/write.