Hacker News Reader

Comment by atemerev | Hacker News Reader

Why people are so afraid of self-modifying code? It enables some cool hacks, it is no more and no less secure than non-self-modifying code (as long as it is properly contained), and, well, this what makes computers and programming interesting rather then limited to boring table lookups and finite state machines.

View on HN

> as long as it is properly contained

Why are people so afraid of C buffers? They enable great performance, and they are no more and no less secure than bounds-checked buffers (as long as the array indices are properly contained), and well, this is what makes computers and programming run fast rather than being forced into slow interpreted execution.

https://en.wikipedia.org/wiki/Poe%27s_law

Self-modifying code is difficult to understand because by definition the code you are looking at might change without you observing the change. So the source code being the 'source of truth' that we are all accustomed to is not true because another line might modify the one your looking at. This problem is similar to heavy use of monkey patching or OOP patterns where "everything happens somewhere else". I'm not arguing for or against self-modifying code, but it is important to note that there is a cost associated with it.

I usually pay homage to Einstein and call this "spooky action at a distance". Apparently I'm not the only one to have seen the connection:

https://en.wikipedia.org/wiki/Action_at_a_distance_%28comput...

"In computer science, action at a distance is an anti-pattern (a recognized common error) in which behavior in one part of a program varies wildly based on difficult or impossible to identify operations in another part of the program."

It wasn't even self-modifying the last time I looked at the unexec code. It was also fairly easy to port to a new architecture.

I have no opinion about who's right or wrong on this, but the article does give multiple reasons to dislike the code -- calling it an "unportable hack" that "few people... will be able to fix when faced with problems", stating that it doesn't seem to have much value, and suggesting two simpler ways to achieve the same desired effect.

In my reading, the author doesn't even complain that it's a security issue, just that it will likely fail on systems with certain security measures. And the author never says it's bad simply because it's self-modifying; rather, that the self-modification is a "platform-specific reimplementation of a linker".

An unportable hack that was ported to 11 operating systems.

A maintenance burden that is over 20 years old still working fine.

The emacs community might think it's "working fine". The glibc community-- which had to forego many bugfixes and optimizations for years, solely because of emacs-- might disagree.

Oh cut me a break. The glibc "community" consists of a cabal of developers who won't fix broken for good reason and break userland for bad reason all the time, admit no wrong, and bring gaping security holes to entire platforms every couple of years. Uri Drepper was the tip of the iceberg. Nothing changed.

unexec is hairy, but it's mature, greybeard hair. It is no worse than any JIT, for starters.

The glibc community has to maintain an API at first, second improve the implementation. They were not able to improve ptmalloc2 to ptmalloc3 over many years, because they were afraid to add memory footprint for better performance. But they happily added more and more debugging hooks which made malloc even more slower for easier development.

But now they want to deprecate malloc_{g,s}et_state(), without a plan to improve ptmalloc2? They already failed.

Deprecating an API for no good reason is failure, not an improvement. It not only breaks emacs, it breaks other software also. unexec is used in perl5 also, btw. just not in the official perl5 packages.

People fear what they don't understand.

When it comes to programs, and unless you're doing research, you should fear what you don't understand. If I have to maintain a program you put into production without understanding it, I will be more than happy to share the fear after I learn your address.

Then refuse yourself from maintaining it.

I love writing self-modifying code. I just hate everybody else's self-modifying code.

I guess the daily updates on the CVE database have something to do with it.

Self-modifying code does not play nice with the advance of CPU and compiler technologies in the past 20 years or so.

I don't get it either; the article sounded like the guy was in way over his head to me.

The fetch-decode-execute cycle is table lookup.

When you have table lookup, and a table is dynamically modified in such a way that this is influenced by the table lookup, that is as "exciting" as self-modifying code.

> Why people are so afraid of self-modifying code?

Because it's several orders of magnitude more incomprehensible than code that fails a cyclomatic complexity check, is why.

People don't like "go to" either:-)

Code that modifies other code but not itself isn't self modifying code.

Self-modifying code is fine. Dumping the process memory in order to modify it is not. Even more so if the majority of the original program was written in a Lisp dialect.

Reply on news.ycombinator.com