[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20211004152816.GC2559@brightrain.aerifal.cx>
Date: Mon, 4 Oct 2021 11:28:16 -0400
From: Rich Felker <dalias@...c.org>
To: Jack Bond-Preston <jack.bond-preston@....com>
Cc: musl@...ts.openwall.com
Subject: Re: Mallocng algorithm high-level overview
On Mon, Oct 04, 2021 at 03:24:28PM +0100, Jack Bond-Preston wrote:
> Thanks for the reply Rich, it has been a great help.
>
> I have a couple more specific questions, sorry:
> - Am I correct in saying IB represents the size (in bytes) of the
> in-band metadata between slots?
> - Is it assumed that sizeof(struct group) == sizeof(UNIT) throughout the
> code (the struct is defined such that this is true)?
UNIT must be large enough to:
- Meet any alignment requirement (be divisible by alignof(max_align_t).
- Hold IB bytes of in-band metadata between slots
- Fit a group header in UNIT-IB (pad[] in group header must be >= IB)
With UNIT==16 this leaves 7 bytes free in the group header on 32-bit
archs and 3 bytes free on 64-bit archs.
> If the size of the
> in-band metadata were to increase (due to additional/larger metadata)
> such that UNIT < sizeof(struct group) (due to the size of the group
> struct needing to increase to accommodate the larger in-band metadata),
> I assume some code would have to be changed to instead use the size of
> the new group struct where appropriate (e.g. when allocating some new
> group).
The fit of small sizeclass groups inside slots of larger ones is
dependent on group header fitting in UNIT. While in theory the header
could be made larger without hard breakage (assuming cleanup to ensure
consistent usage of sizeof(struct group) where appropriate), such a
change would break the math that makes things fit together
efficiently.
In terms of design, group header and in-band metadata ~should not~ be
expanded because they are attack surface and are designed to be
minimal for their purpose. The active_idx was only added to reduce the
physical memory cost/pressure of allocating N slots as a group, due to
divisibility properties of the needed sizeclass, when only 1 or 2
slots are wanted. It's not attack surface; clobbering it will just
lead to premature use of slots intended to be inactive.
> I noticed there are a lot of expressions containing x +
> UNIT/UNIT + x, are these generally to ensure allocations etc. include
> enough space for the contents of the group struct, or are there other
> reasons for these (e.g. some kind of 1-UNIT buffer between slots)?
The only space "between" slots is IB. Where UNIT is added it's
normally to account for a group header (lines 152, 206, 210, 234, 241,
256, 260, 261, 271, 309).
Commit d8715a10b32de699080f820c607db027f0b268b2 in the draft repo
documented this somewhat.
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.
