Build warning about "LOAD segment with RWX permissions"

[nyh]

When building OSv, I see the warning messages:

LINK loader.elf
ld.bfd: warning: build/release.x64/loader.elf has a LOAD segment with RWX permissions
LINK zfs_builder.elf
ld.bfd: warning: build/release.x64/zfs_builder.elf has a LOAD segment with RWX permissions

I don't know what it means, or if there's any harm in these "RWX permissions" and what it takes to fix them.

This warning message isn't new - I think it's around for at least a year, but I only got fed up with it now :-)

[wkozaczuk]

I think this is a fairly new warning about OSv kernel ELF which always was true - a single LOAD segment with code and data in it which is RWE (or RWX):

readelf -Wl build/release/loader-stripped.elf

Elf file type is EXEC (Executable file)
Entry point 0x32517c
There are 5 program headers, starting at offset 64

Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  LOAD           0x000000 0x0000000040200000 0x0000000000200000 0x608084 0x68bca8 RWE 0x1000
  TLS            0x608080 0x0000000040808080 0x0000000000808080 0x000004 0x0006c0 RW  0x10
  DYNAMIC        0x001000 0x0000000040201000 0x0000000000201000 0x000170 0x000170 RW  0x8
  GNU_EH_FRAME   0x5903fc 0x00000000407903fc 0x00000000007903fc 0x01d13c 0x01d13c R   0x4
  NOTE           0x5ad538 0x00000000407ad538 0x00000000007ad538 0x000224 0x000224 R   0x4

I think fairly recently the GNU linker started complaining about it because ideally, a segment should either have code or data (see https://metebalci.com/blog/solution-to-load-segment-with-rwx-permissions-warning-with-cmsis/ for example). Our linker script mixes everything - data and text - into a single segment which is not ideal. I am not sure what repercussions we would see if we separated it. Also I think we would have to make the text segment writable during the boot time to allow modifying code to setup things like the memcpy version, tracepoints enabling, etc.

I think ideally this should be done as part of #651.