bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/30612] maxpagesize alignment after relro segment takes up space


From: i at maskray dot me
Subject: [Bug ld/30612] maxpagesize alignment after relro segment takes up space
Date: Wed, 30 Aug 2023 01:59:56 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=30612

Fangrui Song <i at maskray dot me> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |i at maskray dot me

--- Comment #1 from Fangrui Song <i at maskray dot me> ---
Unfortunately, I believe this is nearly infeasible to fix, as long as the
alignment still follows max-page-size, as switching to a two-RW-PT_LOAD layout
in GNU ld is very difficult.

I have a short summary of different design choices:
https://maskray.me/blog/2020-11-15-explain-gnu-linker-options#z-relro

> GNU ld uses one RW PT_LOAD program header with padding at the start. The 
> first half of the PT_LOAD overlaps with PT_GNU_RELRO. The padding is added so 
> that the end of PT_GNU_RELRO is aligned by max-page-size. (See ld.bfd 
> --verbose output.) Prior to GNU ld 2.39, the end was aligned by 
> common-page-size. GNU ld's one RW PT_LOAD layout makes the alignment increase 
> the file size. max-page-size can be large, such as 65536 for many systems, 
> causing wasted space.
>
> lld utilitizes two RW PT_LOAD program headers: one for RELRO sections and the 
> other for non-RELRO sections. Although this might appear unusual initially, 
> it eliminates the need for alignment padding as seen in GNU ld's layout. I 
> implemented the current layout in 2019 (https://reviews.llvm.org/D58892).
>
> The layout used by mold is similar to that of lld. In mold's case, the end of 
> PT_GNU_RELRO is padded to max-page-size by appending a SHT_NOBITS 
> .relro_padding section. This approach ensures that the last page of 
> PT_GNU_RELRO is protected, regardless of the system page size. However, when 
> the system page size is less than max-page-size, the map from the first RW 
> PT_LOAD is larger than needed.
>
> In my opinion, losing protection for the last page when the system page size 
> is larger than common-page-size is not at all an issue. Protecting .got.plt 
> is the main purpose of -z now. Protecting a small portion of .data.rel.ro 
> doesn't really make the program more secure, given that .data and .bss are so 
> huge and full of attach targets. If users are really anxious, they can set 
> common-page-size to match their system page size.
>
> I am unsure whether lld's hidden assumption about common-page-size <= system 
> page-size is an issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]