Data Execution Prevention

Is a security feature included in modern Microsoft Windows and Unix operating systems that is intended to prevent an application or service from executing code from a non-executable memory region. As a 'security' measure, it mostly hinders SmashingTheStackForFunAndProfit - i.e. overriding the return-address to jump into code that was injected into the stack.

I wonder, since for Lisp code is data and data is code... would it be impossible to implement something like DataExecutionPrevention for Lisp based systems?

I'd certainly hesitate to call it impossible, and I can think of various approaches (like region-based allocations, or simple tagging) that could be used to 'taint' remote code so that it is given to a higher-security evaluator or rejected by evaluator.

But the real question is whether it would be useful.

Lisp like many languages uses certain "ambient" capabilities quite heavily - i.e. code executed on a certain machine gains "rights" to the local machine resources (like the filesystem) by virtue of where it is executing rather than where the code came from. That's the real security issue.

A reasonable, far more secure alternative would be to control the "environment" of evaluation to a greater degree, and to provide stronger encapsulation than Lisp usually provides, in order to confine the rights of 'injected' code. By controlling the environment, the Lisp code could provide exactly the set of "local" capabilities the remote code is allowed to have (i.e. perhaps rights to read from certain local hardware, or interact via certain interfaces with other objects).