Page MenuHomeFreeBSD

libc: stop exposing break/sbrk/brk
AcceptedPublic

Authored by brooks on Dec 1 2023, 1:17 AM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Dec 10, 2:50 AM
Unknown Object (File)
Fri, Nov 29, 11:00 PM
Unknown Object (File)
Wed, Nov 27, 2:20 AM
Unknown Object (File)
Tue, Nov 19, 8:38 PM
Unknown Object (File)
Nov 14 2024, 4:23 PM
Unknown Object (File)
Nov 7 2024, 4:42 PM
Unknown Object (File)
Oct 30 2024, 10:44 AM
Unknown Object (File)
Oct 30 2024, 9:46 AM

Details

Reviewers
andrew
kib
Summary

These interfaces are convoluted, rely on memory layout details that should not be exposed, and are often misued as proxies for other things (e.g., calling sbrk(0) repeatidly to determing heap use.) They are not part of any standard. While we must continue to support them for backwards compatability, most uses can be removed in a straightfoward manner.

Declare the undocumented break(2) system call COMPAT14 and remove public decleration and linkage defintion of it, sbrk, and brk interfaces. A later commit will introduce a libsbrk to allow their use for programs that can not be altered to avoid them (due to the way that tools like autoconf work, the symbol must not be directly linkable to avoid it being found and used even without a decleration).

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 60174
Build 57058: arc lint + arc unit

Event Timeline

brooks requested review of this revision.Dec 1 2023, 1:17 AM

I am fine with marking sbrk as compat14, but it should be done consistently everywhere, i.e. include the implementation.

Previous releases for arm64 were not Tier1 (except 14.0) so this argument does not hold.

I propose to commit both mine change and this change adopted, i.e. have sbrk functional on all Tier1 arches with COMPAT_FREEBSD14.

sys/kern/syscalls.master
504–505

This should become OBSOL I believe. And symbols just provided by libc if they were exported before (I did not rechecked).

504–505

Same.

In D42862#977823, @kib wrote:

I am fine with marking sbrk as compat14, but it should be done consistently everywhere, i.e. include the implementation.

I'm not sure what you mean here.

Previous releases for arm64 were not Tier1 (except 14.0) so this argument does not hold.

What argument?

I propose to commit both mine change and this change adopted, i.e. have sbrk functional on all Tier1 arches with COMPAT_FREEBSD14.

Why would we support sbrk on aarch64 for COMPAT_FREEBSD14 when we don't even ship the symbols in 14.0? We'd just be shipping dead code that might well cause some GNU bits to start linking against the symbol (we ran into problems with binutils when removing it in the first place where binutils would declare the interface internally when libc had it).

sys/kern/syscalls.master
504–505

I'll create a separate review for this.

  • Move sbrk/sstk syscall removal to D42872
  • Rebase

Previous releases for arm64 were not Tier1 (except 14.0) so this argument does not hold.

arm64 is Tier 1 as of 13.0
https://www.freebsd.org/platforms/

Make _brk, brk, and sbrk compat symbols

break(2) was never public, don't start now

In D42862#977823, @kib wrote:

I propose to commit both mine change and this change adopted, i.e. have sbrk functional on all Tier1 arches with COMPAT_FREEBSD14.

Why would we support sbrk on aarch64 for COMPAT_FREEBSD14 when we don't even ship the symbols in 14.0? We'd just be shipping dead code that might well cause some GNU bits to start linking against the symbol (we ran into problems with binutils when removing it in the first place where binutils would declare the interface internally when libc had it).

sbrk should go into FBSD_1.0 on aarch64, as I did in my review. It should not be removed from the visibility list for linking.

But I think it is fine to have the syscall itself to be put under COMPAT14, and enable it (under COMPAT14) on all arches.

I really see no point of trying to hide the interface that is practically used by third-party software and is assumed to be present on all Unixes, regardless of how ugly it is perceived by some part of OS developers.

In D42862#978526, @kib wrote:
In D42862#977823, @kib wrote:

I propose to commit both mine change and this change adopted, i.e. have sbrk functional on all Tier1 arches with COMPAT_FREEBSD14.

Why would we support sbrk on aarch64 for COMPAT_FREEBSD14 when we don't even ship the symbols in 14.0? We'd just be shipping dead code that might well cause some GNU bits to start linking against the symbol (we ran into problems with binutils when removing it in the first place where binutils would declare the interface internally when libc had it).

sbrk should go into FBSD_1.0 on aarch64, as I did in my review. It should not be removed from the visibility list for linking.

But I think it is fine to have the syscall itself to be put under COMPAT14, and enable it (under COMPAT14) on all arches.

I really see no point of trying to hide the interface that is practically used by third-party software and is assumed to be present on all Unixes, regardless of how ugly it is perceived by some part of OS developers.

Due to the way AC_CHECK_FUNC works in autoconf, the only way to stop autoconf using code from linking sbrk when it's not even needed is to make it unlinkable. As a compromise I propose something like D43002 to expose the symbol via a libsbrk.

brooks retitled this revision from Deprecate break/sbrk/brk to libc: stop exposing break/sbrk/brk.Jan 3 2024, 9:56 PM
brooks edited the summary of this revision. (Show Details)
brooks edited the summary of this revision. (Show Details)
  • Rebase

I'm going to commit this against bacula 11, 13, and 15 - my test builds are underway now.

include/unistd.h
475

I think that prototypes for the functions should be provided somehow, might be behind additional symbol check.

Add _WANT_BRK and _WANT_SBRK

This revision is now accepted and ready to land.Oct 23 2024, 10:47 PM