On 19/01/2018 14:14, Claude Frantz wrote:
On 01/19/2018 12:41 PM, Bill Somerville wrote:
Hi Bill & all,
Perhaps is this problem related to the recent effort to avoid W+X pages.
I'm no sure.
if that is the case then it is not acceptable. I cannot think of any
attack vector on the jt9 executable that could do harm that is enabled
by it having an executable stack.
I do not think that such a measure is directed toward a good piece of
software working well. This would not add any security. Just in the case
of a misbehaviour, blocking the overwriting of executable code could
limit the damage and make the debugging easier. In contrast, malware
could make many usages of a changed piece of executable code. The risk
is here.
FORTRAN is a very old programming language. At that time, it was not
usual to have memory protection in RAM. FORTRAN was designed in that
time. Today, many thinks are different, but some ideas on which the
FORTRAN world was based are still present in the current FORTRAN world.
I think that we should simply avoid situations which result in pages
having write and executable flags as well. Of course, the compiler
should not generate such a code. But because of the view of an old
programming language, this is probably not always easy without imposing
limitations on the language itself.
Just my own opinion.
Best wishes,
Claude (DJ0OT)
Hi Claude,
largely agreed but Fortran is not the only language that uses/requires
trampolines on the stack for certain, albeit obscure, facilities. For
example in GNU C (not GNU C++) nested functions
(https://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html) require them too.
I believe restricting the generation of code requiring executable stack
space is not a matter of compiler design but is a case of needing to
remove certain facilities from the languages themselves, as does C++
which does not allow nested functions. It can do so because other
language features allow equivalent techniques (lambdas in recent C++
standards etc.). I am sure that Bjarne and the C++ standards committee
had to think hard about breaking compatibility with C when disallowing
nested functions before viable implementations of lambda closures were
available. I do know that nested functions were rejected by the C++
standards committee but have no references as to why but it was probably
for grounds other than NX stack, maybe no working implementation was
available at the time.
73
Bill
G4WJS.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
