Self-modifying code
Self-modifying code
Posted Jul 28, 2024 9:31 UTC (Sun) by malmedal (subscriber, #56172)In reply to: Self-modifying code by khim
Parent article: May the FOLL_FORCE not be with you
You asked for this earlier:
>> maybe even teach kernel not to ever provide W+X mappings at all
This is an answer, it has a cost, an expensive one, but it is an answer.
Posted Jul 28, 2024 10:00 UTC (Sun)
by khim (subscriber, #9252)
[Link] (2 responses)
Sure, but as was mentioned in the very beginning, seven years ago there are already two other methods (three if you include self-ptrace). You are proposing third (or fourth) one without explaining why it's better than what we already have. This looks like “he have to do something” — “this is something” — “let's do it!” logic. Such logic rarely produces good designs.
Posted Jul 28, 2024 10:57 UTC (Sun)
by malmedal (subscriber, #56172)
[Link] (1 responses)
In discussions like this I believe it is useful to go through many possible options and evaluate their pros and cons without being particularly wedded to any one of them. Since it's an option that meets the specific constraint that you, yourself, chose to highlight, I felt that it should be included in the discussion. This approach appears to be incompatible with your style of arguing, so I'll just be ignoring you from now on.
Posted Jul 28, 2024 12:05 UTC (Sun)
by khim (subscriber, #9252)
[Link]
Why? What have that approach brings to you? What have you achieved doing it? I find that very strange. Things that we already have, things that exist, by definition, have a priority. They are already here, they are done, that enough. But any change from the status quo need a justification. Sure, I like to go “back the memory lane” and see why things that we have are like they are. Because situation of today is different from situation of yesterday. But no matter what, even if the thing that made us to pick original decision is no longer valid or even if the original decision was made on a whim without any rational justifications… things that we have are very-very different from things that we don't have. One may invent bazillion crazy schemes if not constrained by anything. Talking about them would take forever unless we would limit these discussions, somehow. “Anything new should come with an extra justification that explains why should we do that if some other solution already exists” is very good rule if we are talking about something that we plan to implement. I don't know anyone who achieved anything significant while violating it (but note the subtle difference: if we don't yet have a solution at all then someone who doesn't “know” that “X is simply impossible” may achieve something really cool… but when said X is not just possible in theory but we already know how to do X in practice then situation chances). Well, maybe fiction writers would be an exception, but even they, when they construct their strange imaginary worlds, still play on that contrast between what “we” have and what “they” have. “Does it exist?” is still very much a central question that governs their decisions even if they imagine a world where something that we already have doesn't exist and where evolution of civilization, as a consequence, goes into a different direction. Fine by me. I don't like to waste time on pointless discussions without any practical consequences (even if the consequence is minor like “now that I have wrote that I may just refer people here instead of repeating my arguments again and again”) while you seem to regard these as the only ones worthy of pursuing.
> This is an answer, it has a cost, an expensive one, but it is an answer.
Self-modifying code
Self-modifying code
> In discussions like this I believe it is useful to go through many possible options and evaluate their pros and cons without being particularly wedded to any one of them.
Self-modifying code