libc: stop exposing break/sbrk/brk

[brooks]

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).

[kib]

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.

[brooks]

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.

[brooks]

• Move sbrk/sstk syscall removal to D42872
• Rebase

[emaste]

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/

[brooks]

Make _brk, brk, and sbrk compat symbols

[brooks]

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

[kib]

In D42862#977863, @brooks 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.

[brooks]

In D42862#978526, @kib wrote:

In D42862#977863, @brooks 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]

• Rebase

[dvl]

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

[brooks]

Rebase

[brooks]

Rebase

[kib]

include/unistd.h

475

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

[brooks]

Add _WANT_BRK and _WANT_SBRK