Stabilization report

RELRO (Relocation Read-Only) is a binary hardening technique, it makes the Global Offset Table (GOT) read-only (preventing some avenues of exploitation).

Roughly speaking, calls to functions from dynamic libraries are implemented using the Global Offset Table (GOT) and Procedure Linking Table (PLT) in an ELF file. A call to foo from a foreign library is codegen'd to a call into a stub in the PLT, foo@plt, which looks up the GOT for the real address of foo. If this is the first time that foo has been called, then that won't be known, and the fallback stub's address will be in the GOT and that will be jumped to instead. The fallback handler calls into ld.so to resolve the function and then writes its address into the GOT. Subsequent calls to foo@plt will just jump straight to foo.

This scheme necessitates that the GOT is writable, which opens up the possibility for exploitation. Full RELRO resolves all the function addresses when the program is initially loaded and populates the GOT eagerly - this uses more memory and increases process startup time - but it allows the GOT to be made read-only (both .got and .got.plt). Partial RELRO only makes the non-PLT part of the GOT read-only (.got), but .got.plt is still writable. Both partial and full RELRO re-order sections to protect them from being written by buffer overflows.

rustc allows configuration of RELRO levels with -Zrelro-level={off,partial,full} and if this isn't set, then each target can set a default RELRO level. We enable full RELRO on many of our targets by default (e.g. Linux, BSD, etc).

This feature has been implemented since 2017 and has been enabled by default for most platforms on which it is enabled since that initial implementation.

If we don't enable RELRO by default on a target, then users have no way of requesting it on stable toolchains. If RELRO is undesirable, then users have no way of disabling it on stable toolchains.

As per other platform-specific codegen flags, this option is ignored on those targets (e.g. like -Ccontrol-flow-guard on non-Windows targets).

Tests

• tests/run-make/relro-levels

History

• Add support for full RELRO #43170 (initial implementation)
• Add relro-level tests #48388 (bug fix test)

Unresolved questions

• None!

r? @JohnTitor

rustbot has assigned @JohnTitor.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Some questions:

• Is this only relevant for the link step? i.e., would users wanting to disable it need -Zbuild-std?
• Do we have any targets which support this but don't enable it at full by default at tier 2 ?

• Is this only relevant for the link step? i.e., would users wanting to disable it need -Zbuild-std?

This does just pass flags to the linker. It would be useful with -Zbuild-std but also with no_std.

As far as I can tell, RELRO can be applied to shared objects as well as binaries, so you could have std with RELRO and the rest of your application without, or you could build a shared library to link with a C/C project and have that library use RELRO or not. I'm not completely certain about this, as the documentation about the linker flag is a little sparse, but I can observe that shared objects from libraries have RELRO in their program headers, so I assume it makes sense for libraries to have it.

• Do we have any targets which support this but don't enable it at full by default at tier 2 ?

From a cursory review of tier 2 targets, it seems like we don't enable Full RELRO by default on Windows, Solaris/Illumos, Apple, Fuchsia, WebAssembly, and *-unknown-none targets. Some of these obviously don't support RELRO, like Windows or WebAssembly, as they don't use ELF. I'm not familiar enough with the others to say, and couldn't work it out with some brief research.

I don't think I'm a good reviewer here, r? @Mark-Simulacrum

Makes sense.

Some of these obviously don't support RELRO, like Windows or WebAssembly, as they don't use ELF

I'd imagine Windows has some equivalent, but I guess we don't have to expose it all under the same flag, especially if the defaults are mostly on the "secure" side of things rather than not.

@davidtwco do you want to kick off FCP? I don't think I can do that myself.

@rfcbot fcp merge

Team member @davidtwco has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Aaron1011
• @cjgillot
• @compiler-errors
• @davidtwco
• @eddyb
• @estebank
• @jackh726
• @lcnr
• @matthewjasper
• @michaelwoerister
• @nagisa
• @oli-obk
• @petrochenkov
• @pnkfelix
• @wesleywiser

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

🔔 This is now entering its final comment period, as per the review above. 🔔

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

@Mark-Simulacrum this is ready to be reviewed and approved now that the FCP has finished

@bors r rollup

📌 Commit 420c58f has been approved by Mark-Simulacrum

It is now in the queue for this repository.