Currently, the default value of `-z max-page-size` and `-z common-page-size` are 65536 and 4096 on ARM64, respectively. That means an executable created by GNU ld with the default settings works on any system whose page size is equal to or smaller than 65536, but the RELRO segment may not be protected on systems with >4096 byte pages. RELRO works on page granularity. When GNU ld creates a PT_GNU_RELRO segment, it uses the common page size as a page size. At runtime, both the start and the end address of a PT_GNU_RELRO segment are _rounded down_ to the actual system's page size. So, if the common page size is smaller than the max page size, it is not guaranteed that an entire RELRO segment becomes read-only after process initialization. I think this can cause a security issue. Asahi Linux uses 16 KiB pages, so the above situation is I think becoming real. Maybe we should bump the common page size to 16 KiB on ARM64?
(In reply to Rui Ueyama from comment #0) > So, if the common page size is smaller than the max page > size, it is not guaranteed that an entire RELRO segment becomes read-only > after process initialization. That used to be the case, but with current mainline the RELRO segment ought to be max page size aligned. See pr28824
Oh, I didn't know that that change has been made. Thank you for your quick response! I'm closing this issue as a duplicate. *** This bug has been marked as a duplicate of bug 28824 ***
Oh, I didn't know that that change has been made. Thank you for your quick response! I'm closing this issue as a duplicate.