Trouble with new GNU_STACK segment

[Frank Wille <frank%phoenix.owl.de@localhost>]

Hi!

These days I tested a current ibmnws kernel on my Network Station and it
was rejected by the firmware (bad size, file corrupted). An older, NetBSD-6
kernel, worked. So I was looking for reasons and finally found that the
additional GNU_STACK segment in the kernel is the problem.

"readelf -l" on NetBSD-6 kernel:

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000080 0x00100000 0x00100000 0x4240b8 0x441fe0 RWE 0x40

 Section to Segment mapping:
  Segment Sections...
   00     .text .rodata link_set_modules link_set_bufq_strats
link_set_sysctl_funcs link_set_dkwedge_methods link_set_malloc_types
link_set_evcnts link_set_domains link_set_prop_linkpools .data
.data.cacheline_aligned .data.read_mostly .sbss .bss 

"readelf -l" on current kernel:

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000080 0x00100000 0x00100000 0x1f7a4c 0x210d20 RWE 0x40
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4

 Section to Segment mapping:
  Segment Sections...
   00     .text .rodata .eh_frame link_set_sysctl_funcs link_set_modules
link_set_domains link_set_evcnts link_set_bufq_strats
link_set_dkwedge_methods link_set_prop_linkpools .data .bss 
   01     


When I patch this current kernel manually and remove the additional segment,
then it is loaded again and works!

Unfortunately I found nothing to prevent the GNU_STACK segment from
appearing
in the kernel. I tried a modified linker script with:
  /DISCARD/ : { *(.note.GNU-stack) }

I even wrote a script to remove the .note.GNU-stack section from all of the
kernel's objects. The linker still creates the new segment.

Is there anything we can do about it? In my understanding GNU_STACK has only
a meaning for programs executed by the kernel (at least under Linux), and
defines whether code execution on the stack is allowed or not. But it is
irrelevant for the kernel itself.

There may be more firmware which doesn't like it.

-- 
Frank Wille