Executable stacks in json-fortran

[susilehtola]

Hi, I'm the Fedora maintainer of json-fortran.

Fedora's security criteria are always developing and nowadays executable stacks in code are forbidden.
json-fortran's builds started failing recently because of this:

/usr/bin/ld: error: /tmp/cc6PCWTr.ltrans0.ltrans.o: is triggering the generation of an executable stack (because it has an executable .note.GNU-stack section)
/usr/bin/ld: failed to set dynamic section sizes: file format not recognized
collect2: error: ld returned 1 exit status

I have faced a similar issue with some other Fortran code (OpenMolcas), where the issue was caused by internal procedures (functions within functions); moving the function outside of the function removed the executable stack and fixed the packaging issue. I am not sure what is the problem with json-fortran.

See the Fedora bug report for build log files
https://bugzilla.redhat.com/show_bug.cgi?id=2385086

[jacobwilliams]

JSON-Fortran does use functions contained within other functions in various places (this is a standard Fortran technique). Can you tell me what compiler is being used here, and what compile/link flags are being used?

[jacobwilliams]

Reference: there is some discussion of gfortran & executable stacks here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117455 I don't pretend to understand it all.

[Kooky089]

The issue happens, when you take the procedure pointer of an internal function and pass it as an argument to another function. This happens at following lines in the code:

Internal subroutine get_string_lengths at

json-fortran/src/json_value_module.F90

Line 1502 in 40e6ccc

call json%get(p, array_callback=get_string_lengths)

Internal subroutine is_child_of_callback at

json-fortran/src/json_value_module.F90

Line 2685 in 40e6ccc

call json%traverse(p1%children,is_child_of_callback)

Internal subroutine duplicate_key_func at

json-fortran/src/json_value_module.F90

Line 5823 in 40e6ccc

call json%traverse(p,duplicate_key_func)

Internal subroutine get_int_from_array at

json-fortran/src/json_value_module.F90

Line 8292 in 40e6ccc

call json%get(me, array_callback=get_int_from_array)

Internal subroutine get_real_from_array at

json-fortran/src/json_value_module.F90

Line 8542 in 40e6ccc

call json%get(me, array_callback=get_real_from_array)

Internal subroutine get_logical_from_array at

json-fortran/src/json_value_module.F90

Line 9029 in 40e6ccc

call json%get(me, array_callback=get_logical_from_array)

Internal subroutine get_chars_from_array at

json-fortran/src/json_value_module.F90

Line 9279 in 40e6ccc

call json%get(me, array_callback=get_chars_from_array)

Internal subroutine get_chars_from_array at

json-fortran/src/json_value_module.F90

Line 9407 in 40e6ccc

call json%get(me, array_callback=get_chars_from_array)

That can be fixed by either not passing those internal subroutines to other functions or moving them one level up. The latter way is probably the way to go, but needs some refactoring as captures of the main functions data will not work anymore.

For testing you could use (docker) debian 13, gfortran and cmake e.g.:

container@733cb724b342:/workspaces/json-fortran$ cmake -S . -B build && make -C build
CMake Warning (dev) at CMakeLists.txt:29 (enable_language):
  project() should be called prior to this enable_language() call.
This warning is for project developers.  Use -Wno-dev to suppress it.

-- The Fortran compiler identification is GNU 14.2.0
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Check for working Fortran compiler: /usr/bin/f95 - skipped
-- CMake build configuration for JSON-Fortran 9.0.5
-- Configuring done (0.2s)
-- Generating done (0.1s)
-- Build files have been written to: /workspaces/json-fortran/build
make: Entering directory '/workspaces/json-fortran/build'
[  7%] Building Fortran object CMakeFiles/jsonfortran.dir/src/json_kinds.F90.o
[ 15%] Building Fortran object CMakeFiles/jsonfortran.dir/src/json_parameters.F90.o
[ 23%] Building Fortran object CMakeFiles/jsonfortran.dir/src/json_string_utilities.F90.o
[ 30%] Building Fortran object CMakeFiles/jsonfortran.dir/src/json_value_module.F90.o
[ 38%] Building Fortran object CMakeFiles/jsonfortran.dir/src/json_file_module.F90.o
[ 46%] Building Fortran object CMakeFiles/jsonfortran.dir/src/json_module.F90.o
[ 46%] Linking Fortran shared library lib/libjsonfortran.so
/usr/bin/ld: warning: CMakeFiles/jsonfortran.dir/src/json_value_module.F90.o: requires executable stack (because the .note.GNU-stack section is executable)
[ 46%] Built target jsonfortran
[ 53%] Building Fortran object CMakeFiles/jsonfortran-static.dir/src/json_kinds.F90.o
[ 61%] Building Fortran object CMakeFiles/jsonfortran-static.dir/src/json_parameters.F90.o
[ 69%] Building Fortran object CMakeFiles/jsonfortran-static.dir/src/json_string_utilities.F90.o
[ 76%] Building Fortran object CMakeFiles/jsonfortran-static.dir/src/json_value_module.F90.o
[ 84%] Building Fortran object CMakeFiles/jsonfortran-static.dir/src/json_file_module.F90.o
[ 92%] Building Fortran object CMakeFiles/jsonfortran-static.dir/src/json_module.F90.o
[100%] Linking Fortran static library lib/libjsonfortran.a
[100%] Built target jsonfortran-static
make: Leaving directory '/workspaces/json-fortran/build'

If one just removes the lines above for testing, the warning about the executable stack goes away.

[jacobwilliams]

Are you on an x86_64 machine?

I'm on an ARM Mac and I don't see this issue with gfortran 14.2.0.

Does using this ftrampoline-impl flag make any difference for you?

[Kooky089]

Yes x86_64 machine. You could also check your Ubuntu CI job for the warning about the executable stack https://github.com/jacobwilliams/json-fortran/actions/runs/17224564245/job/48866644858#step:12:37

I haven't tried that flag. It looks a bit like a workaround, since it doesn't guarantee deallocation of heap trampolines in every case, but it might work.

[jacobwilliams]

Thanks! I never noticed the warning in the CI. Now at least I can try to prototype some changes and test in the CI to see what happens.

But really this seems like a compiler issue though right? If this commonly-used Fortran idiom is banned on some systems, it should be up to Gfortran to provide some option to generate compliant code on those systems.