[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190402195830.GN23599@brightrain.aerifal.cx>
Date: Tue, 2 Apr 2019 15:58:30 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Changes for upstream?
On Tue, Apr 02, 2019 at 07:11:14PM +0000, Jewell Seay wrote:
> Hello,
>
> The team I am on is in the beginning stages of making the following
> changes to musl, would upstream desire any of these?
>
> - Heap hardening: adding cookies and validation to increase the
> likelihood of crashing if someone corrupts heap memory (as a
> security mitigation).
Additional validation is desirable, but the existing malloc
implementation in musl is not intended to be kept long-term, so doing
and reviewing work on it is maybe not a good use of time...
> - Randomizing library locations in memory (while keeping the ordering
> of module _init and _fini calls stable).
I'm confused why this would be in musl and not just by the kernel's
normal ASLR. On 32-bit you really can't randomize positions because
the address space is just too small, but on 64-bit, doing strong mmap
ASLR in the kernel would get you this for free. Do you have a
different/better method in mind that could be achieved in the dynamic
linker but not in the kernel?
> - Shrink the memory footprint of the DATA and BSS sections.
That would be nice, but for the most part I don't think any further
reduction is possible without introducing places where no forward
progress is possible because memory needed was not reserved in
advance. Obviously the stdio buffer sizes could be decreased but that
would hurt performance a lot.
> - Return memory to the kernel within free().
This is already done via MADV_DONTNEED. Using MADV_FREE has been
suggested recently and would probably be a good idea; it looks like it
could be swapped in without any complex work. There are also a few
past threads where I discussed a desire to return not just the dirty
page pressure, but the commit charge, to the kernel when there are
huge free chunks. There are tradeoffs involved, and with the current
allocator slated to be replaced, I didn't really want to spend a lot
of effort considering how they'd fit in with it.
> The other question we have is that it does not appear that there is
> any standard way in musl to have certain functionality turned on or
> off. If any of these changes are desired to be optional then is
> there an accepted method for enabling or disabling the feature?
It's intentional that we don't have functionality switches, but of
course due to CFLAGS various degrees of hardeing are already possible
(stack protector, stack clash check, etc., even UBSan) so it's
conceivable that we could add things that require conditionals at the
source level. Any such things should not affect the exposed interfaces
or the observable behavior of programs with well-defined behavior. But
ideally good hardening measures are sufficiently inexpensive that
making them optional is not needed. The main cost, which should always
be minimized, is the source-level complexity, and that's same or worse
when they're optional.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
