Page MenuHomeFreeBSD

Enable ASLR by default for 64-bit executables.
Needs ReviewPublic

Authored by mw on Dec 18 2020, 4:51 AM.

Details

Summary

Tests on the main 64-bit architectures prove that the ASLR is stable and does
not result in noticable performance degradation.

For 64-bit executables set honor_sbrk to 0. This allows ASLR to use
bss grow region for mappings. Sbrk is currently deprecated and not
widely used, so this setting should not have any significant impact
on the OS memory footprint.

On 32-bit architectures the implementation is however still unstable

Contrary to other test-cases the issues were encountered when trying to perform buildworld.
For the sake of safety keep ASLR is disabled for 32-bit executables on 64-bit machines, too.

Test Plan

Validation summary of the ALSR/PIE feature enablement in FreeBSD-HEAD:
https://drive.google.com/file/d/1Ujdiv2aN9kiD0dnjvH7VlqpwOPdA-xDK

It comprises a verification whether the change introduces any functional/performance regression in the OS. It also presents a comparison of the results between all used setups:

  • amd64 desktop
  • amd64 server
  • arm64 server
  • armv7 board

Following test cases were executed:

  • buildworld
  • kyua
  • WRK
  • openssl speed

Diff Detail

Repository
R10 FreeBSD src repository
Lint
Lint Skipped
Unit
Unit Tests Skipped

Event Timeline

mw requested review of this revision.Dec 18 2020, 4:51 AM
greg_unrelenting.technology added inline comments.
sys/kern/imgact_elf.c
206

Since https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239873 is not yet resolved, maybe disable stackgap out of the box for now?

sys/kern/imgact_elf.c
206

Hi! Any thoughts about the patch? Do you have objections to get it merged?

Hi! Any thoughts? If no objections, I plan to merge the patch after February 5th.

Thanks @emaste. Is there any part requiring additional work / contribution? If yes, please reach me out, so we can sync and help with whatever is needed.

In D27666#629463, @mw wrote:

Thanks @emaste. Is there any part requiring additional work / contribution? If yes, please reach me out, so we can sync and help with whatever is needed.

Mainly I think we need to make a concerted effort towards identifying ports that require ELF feature tags to opt out of various features, and some common mechanism (either infrastructure or template approach) for setting those bits. I submitted PR252629

As above PR239873 reports issues with firefox and thunderbird with ASLR stack gap. I found libreoffice is incompatible with W^X and submitted PR252689 for that.

share/mk/bsd.opts.mk
64 ↗(On Diff #80880)

IMO we should tackle this change first, in isolation, and commit this part ASAP.

There is a somewhat of an open question if we should change this for i386 (since i386 is register-starved and PIE is relatively more costly there compared to amd64, and because the primary motivation for building PIE is to enable ASLR, which is not particularly interesting on 32-bit archs).

share/mk/bsd.opts.mk
64 ↗(On Diff #80880)

IMO we should tackle this change first, in isolation, and commit this part ASAP.

I will prepare a revision for that then. I think it would be useful to have it in HEAD an later rely only on the sysctl knob settings.

There is a somewhat of an open question if we should change this for i386 (since i386 is register-starved and PIE is relatively more costly there compared to amd64, and because the primary motivation for building PIE is to enable ASLR, which is not particularly interesting on 32-bit archs).

Apart from the memory starvation during buildworld, 32-bit seem to work but I agree it may be better to omit them (at least for now).

About the change itself I'm thinking about adding below in share/mk/src.opts.mk:

.if ${__T} == "aarch64" || ${__T} == "amd64" || ${__T:Mmips64*} || ${__T} == "powerpc64"
__DEFAULT_YES_OPTIONS+=PIE
.else
__DEFAULT_NO_OPTIONS+=PIE
.endif

What do you think?

share/mk/bsd.opts.mk
64 ↗(On Diff #80880)

I think that would be fine with RISC-V added.

In D27666#629463, @mw wrote:

Thanks @emaste. Is there any part requiring additional work / contribution? If yes, please reach me out, so we can sync and help with whatever is needed.

Mainly I think we need to make a concerted effort towards identifying ports that require ELF feature tags to opt out of various features, and some common mechanism (either infrastructure or template approach) for setting those bits. I submitted PR252629

As above PR239873 reports issues with firefox and thunderbird with ASLR stack gap. I found libreoffice is incompatible with W^X and submitted PR252689 for that.

WRT ports do you see a better option than enable PIE/ASLR by default, let the community / port maintainers identify problems, create PR's and opt-out this option until fixed?

In D27666#629768, @mw wrote:
In D27666#629463, @mw wrote:

Thanks @emaste. Is there any part requiring additional work / contribution? If yes, please reach me out, so we can sync and help with whatever is needed.

Mainly I think we need to make a concerted effort towards identifying ports that require ELF feature tags to opt out of various features, and some common mechanism (either infrastructure or template approach) for setting those bits. I submitted PR252629

As above PR239873 reports issues with firefox and thunderbird with ASLR stack gap. I found libreoffice is incompatible with W^X and submitted PR252689 for that.

WRT ports do you see a better option than enable PIE/ASLR by default, let the community / port maintainers identify problems, create PR's and opt-out this option until fixed?

portmgr@ can do an exp-run make a bugzilla with the patch and request similar to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214864

Update revision after splitting PIE enablement to a separate patch (https://reviews.freebsd.org/D28328)

I created D29550, D29551, D29552 and D29553, which allow us to disable stack gap for ntpd during build.