Page MenuHomeFreeBSD

Disable use of sbrk(2).
AbandonedPublic

Authored by brooks on Mar 10 2016, 4:15 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Feb 7, 3:15 AM
Unknown Object (File)
Fri, Feb 7, 2:25 AM
Unknown Object (File)
Fri, Feb 7, 2:20 AM
Unknown Object (File)
Nov 19 2024, 1:26 PM
Unknown Object (File)
Oct 4 2024, 11:20 PM
Unknown Object (File)
Oct 1 2024, 1:20 PM
Unknown Object (File)
Sep 19 2024, 7:32 PM
Unknown Object (File)
Sep 7 2024, 8:25 AM
Subscribers

Details

Reviewers
None
Summary

Disable a couple tests that use sbrk(2).

Don't build brk(2) and sbrk(2) symbols in libc.

Remove declerations for brk(2) and sbrk(2).

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 2843
Build 2867: arc lint + arc unit

Event Timeline

brooks retitled this revision from to Disable use of sbrk(2)..
brooks updated this object.
brooks edited the test plan for this revision. (Show Details)

This patch is not intended to be committed directly as it removes symbols that may not be removed. It is intended to be a patch to test the implications of removing sbrk.

Could the parts of the patch that just change the #define to stop using sbrk be committed?

So why move away from using it?

include/unistd.h
474

I'm assuming this chunk is what you're talking about...

lib/libc/sys/Makefile.inc
18

And this too...

lib/libc/tests/gen/Makefile
16

Is this related? or does dir_test use sbrk?

lib/libc/tests/sys/Makefile
7

Ditto here.

The sbrk interface is lousy. It defeats ASLR, effectively makes freeing memory impossible, and encourages fragmentation. It's also impossible to implement on memory safe platforms like CHERI.

Most users are using it out of inertia and are either using it as a completely non-functional way to infer heap size or could be served by a trival mmap based implementation.

I'm hoping that we can cut the cord for new platforms (arm64 and risc-v). I'm planning to implement trivial implementations as required.

lib/libc/tests/gen/Makefile
16

yes

Could the parts of the patch that just change the #define to stop using sbrk be committed?

The config.h ones probably should be committed since those uses are pointless. I'm less confident of the jemalloc change, but almost certainly if we do import an ASLR implementation.

We've done the most important bits of as part of removing sbrk and brk from arm64 and riscv. We should do the toolchain bits eventually.