[Phoenix-pm] perl eval and the No Execute chips

Paul Balyoz paulio10 at gmail.com
Thu Sep 14 10:08:25 PDT 2006

On 9/14/06, Scott Walters <scott@> wrote:
> >    1. it compiles the source code, producing a binary version really
> >    really quickly
> "Binary" implies "machine code", which would be incorrect in this case.
> perl compiles Perl to "bytecode", which as far as the computer is concerned,
> is just data.  And it is just data, really.  It's meaningless to the
> computer itself, but perl understands it.  It's shorthand -- it's still
> Perl source code (and can be turned back to sourcecode, minus formatting
> and comments).  No-Execute protection on a page keeps the processor from
> executing binary machine code in that page; it doesn't keep it from running
> other programs (such as perl) that read data in that page and then do things
> depending on the data read.

This was a misunderstanding on my part - thank you for the
clarification.  Perl does in fact generate byte-code, not pure
executable machine code.  My bad.

> You fool!  Don't pass off a weak mistranslation of actual events as a
> proof of security.  The more you understand CompSci, the more you
> realize security is as fleeting as a cloud formation or a ripple in
> a pond -- or a fashion movement. ...

Can you find a polite way to respond to people?  I mean really, we're
a community here.  We can all learn from each other.  Be nice.

> ...At no point in history have computers
> been actually effectively secured in a way that they remained secure
> as technology progressed, yet people insist on talking about things
> in terms of "secure" and "not secure".  That's not even adequate for
> a manager's understanding.  Intruders do their work by...<long soliloqy on security>

Oh good, you understand two basic tenets of computer security:
"there is no absolute security.  there can only be more security, or
less security."
And, "all security can be defeated, it's just a matter of time."

With that said, I'd like to suggest that it sounded to me that people
were worried their exec() code was going to fail, not be "insecure".
I don't see how a No Execute flag could cause exec's to be less
secure, only that their existing perl code might fail (which is not
true, as you know).

The point of my post suggested that they don't need to worry about
code-breakage due to the use of exec(), with a No Execute flag set on
each data memory page.

Yes, there are safe and unsafe ways of exec'ing code -- in any
language.  That is a different discussion, which has been discussed
extensively on the Internet for the last 15 or so years.

-- paul

Paul Balyoz
Fastech Learning Center

More information about the Phoenix-pm mailing list