[PATCH] Linux/x86: Enable --rosegment by default

[Fangrui Song]

On Wed, Mar 18, 2026 at 9:21 AM hev <r@hev.cc> wrote:
>
> Hello,
>
> On Wed, Mar 18, 2026 at 11:01 PM Michael Matz <matz@suse.de> wrote:
> >
> > Hello,
> >
> > On Wed, 18 Mar 2026, hev wrote:
> >
> > > This patch looks acceptable to me, and it’s good to see progress here.
> > > That said, in some cases, -z noseparate-code can be more helpful for
> > > THP. I explained the reasoning in another thread. [1][2]
> > >
> > > Also, I’m a bit curious: GNU ld with --rosegment doesn’t seem to
> > > arrange segments as R, RE, RW. From a security perspective, it would
> > > make more sense to put R first so the ELF header is not executable.
> >
> > I we'd continue to care for gadget avoidance, which Florian tells us is
> > not a thing anymore (yippie! :) ).
>
> In practice, GNU ld only enables --separate-code by default for
> Linux/x86. That means most Linux distros on other arches are
> effectively not using it. I’m not really sure how much security
> benefit this actually brings in practice.
>
> >
> > > LLVM lld with --rosegment does this by default (R, RE, RW).
> >
> > But your point in these mails is to align the E part to huge-page borders.
> > Putting a read-only blob in front of it defeats that purpose.
>
> Yeah, that’s exactly why I’m concerned that --rosegment in GNU ld
> might eventually move toward a more security-oriented layout like lld
> (R, RE, RW).
>
> >
> > > I wonder whether relying on the current GNU ld --rosegment layout is
> > > entirely stable, if it ever shifts towards a more security-driven
> > > layout, it might not behave the way we expect here.
> >
> > Hmm?  Your proposal even was to completely merge the read-only and exec
> > segment into one.  You cannot at the same time care and not care about the
> > security implications of merging readonly data and code :)
>
> From the motivation of this patch, I’m personally leaning toward
> performance. If we can’t have both security and performance at the
> same time, then maybe the linker should offer both options so users
> can choose based on their needs:
>
> * --separate-code + --rosegment: security-oriented. This would also
> allow --rosegment to evolve toward a safer layout (RE, R, RW -> R, RE,
> RW), similar to what lld does today.
> * --noseparate-code: performance-oriented, providing a stable (RE, RW) layout.
>
> Thanks,
> Rui

For x86, --no-rosegment -z noseparate-code -z max-page-size=2097152 is
the most compact layout that works with transparent hugepages.
Google and ChromeOS have been using such a layout for a long time.

If you use --rosegment to separate R and RX segments, there is a trade-off

* With -z separate-code , THP works well for the code segment.  The
cost is massive file size inflation due to 2MiB padding between the R
and R+X segments.
* With -z noseparate-code, the RX segment starts at a non-aligned
address. Last time I checked, Linux kernel's THP requires both the
file offset and the VMA start to be huge-page-aligned, so the code
segment cannot use THP.

"In -z noseparate-code layouts, the file content starts somewhere at
the first page, potentially wasting half a huge page on unrelated
content." However, the file size saving advantage outweighs this THP
concern.
(https://maskray.me/blog/2023-12-17-exploring-the-section-layout-in-linker-output)


Gadget avoidance has always been more security theater than substance.
It's irrelevant when talking about --[no-]rosegment and -z
[no]separate-code preference.


GNU ld's issues:

* -z separate-code suppresses --rosegment/--no-rosegment. In LLD the
two options are orthogonal.
* The default linker script places readonly sections after RX
sections, which is not ideal
(https://sourceware.org/bugzilla/show_bug.cgi?id=23704)