Type aware allocators

[CasperN]

I don't know if the ship has sailed on the Allocator trait's API yet, but I think it is a good idea to have an allocate/deallocate variant that is parameterized by T. I'll just call them "Type aware allocators". There are a few security opportunities w.r.t. heap exploits and maybe performance ones too.

Implementations must be backwards compatible, which means if a pointer is allocated with T, deallocating with U where T and U have the same size and alignment must succeed, unless users opt into other behavior.

Benefits:

1. Allocations that contain secret material should be stored on separate pages. With ASLR and guard pages, its difficult for an attacker with a heap overflow to reliably find and exploit this material. Having T in the API lets libraries hint to a shared allocator to get this separate treatment. Currently, libraries containing secrets would have to manage their own allocator.

2. Similarly, an attacker with a heap overflow may want to exploit function pointers.

One mitigation employed by the Scudo hardened allocator involves "quarantining" free'd pointers and freeing them at a later point. This makes heap attacks less reliable too but kills memory locality: Imagine you're allocating and deallocating a string in a tight loop, tcmalloc and jemalloc will give you the same (hot) memory each time while quarantining forces you into something colder. So for performance reasons, this security feature is often disabled. In some sense, quarantining all pointers is overkill. Function pointers are more dangerous than, e.g., a vector of ints.

3. It might be a red flag if a program allocates a pointer and de-allocates it with a different type. This probably happens a lot already for existing code, but for new opt in types in completely safe code, this may point to malicious behavior and the allocator should terminate the program.

4. For performance reasons, it might be a good idea to put long lived shared data on different pages than hot, thread local data. This reason is a little iffy since a performance sensitive user should probably go with a locally scoped allocator to keep its memory nearby.

5. More performance reasons: Slab allocators

[CasperN]

Chrome's PartitionAlloc separates strings: https://blog.chromium.org/2021/04/efficient-and-safe-allocations-everywhere.html

https://chromium.googlesource.com/chromium/src/+/dcc13470a/third_party/WebKit/Source/wtf/PartitionAlloc.md#partitions-and-buckets

[CeleritasCelery]

I can certainly see the benefit of type of allocators for different types. But monomorphizing every allocation site seems quite expensive. With the allocator API you can pass different allocators to different allocatable functions, so there would be no need to make it generic, at least not that I can see.

[CasperN]

But monomorphizing every allocation site seems quite expensive

I agree that it seems to be a potentially expensive compile time cost, and should be kept in mind when exploring this direction.

My intuition is that a similar cost is already paid by Layout::new() which is generic over T and presumably also present at most/all allocation sites. I'd expect the additional cost to be comparable. Additionally, implementers can be recommended to keep allocate<T>optimizable to a single call to a more specific allocator function. Basically use T and const functions to decide on the more specific function, the const function and branching will be optimized away.

With the allocator API you can pass different allocators to different allocatable functions, so there would be no need to make it generic, at least not that I can see.

While its true that programmers can manage multiple allocators, I do not think that is the best way to solve the above class of problems. It is not possible to enforce for large groups of programmers over a long period of time. It is not easy to do backwards compatibly if there is a new security/performance technology.

There needs to be a mechanism for a type to choose allowable allocators for its containers or allocators need to be aware of the types it consumes. The latter is better because the cost is put on the allocator writer rather than the allocator user.

[CeleritasCelery]

Touché. Those are all good points. I am convinced so long as the generic overhead is not too high.

[scottmcm]

I think this would prevent Vec::from_raw_parts conversions that are legal today, right? (Or, at least it would if the global allocator could do this. I suppose that we could make Vec::from_raw_parts_in also require that the type is an exact match, since it's not stable yet, but I don't think that's desirable.)

The C++ part of my brain says that the way to meet the desire here (assuming for now it's worth doing) is to specialize the choice of allocator, not specialize the allocator. So, for example, it could be Vec<T, A = <T as PickDefaultAllocator>::Type> instead of Vec<T, A = GlobalAllocator>. That way allocators still don't need to know what type they're allocating and once you're using a specific allocator the rebuild-for-different-but-layout-compatible-type still works.

[Ericson2314]

There has been work with single type "slab allocators" of this sort before. CC @joshlf

[CasperN]

I think this would prevent Vec::from_raw_parts conversions that are legal today, right?

@scottmcm

We must still keep the contract of "allocate and deallocate with the same size and alignment" for backwards compatibility, so no. Idea 3 above should not be enforced on existing types. I think a fast deallocate path may assume that allocate used the same type but it should always fail back to a slower path if that is not true, except if a programmer opted into specific behavior. E.g. Foo: DeallocatedTypeMatchesAllocatedTypeOrAbort

The C++ part of my brain says that the way to meet the desire here (assuming for now it's worth doing) is to specialize the choice of allocator, not specialize the allocator. So, for example, it could be Vec<T, A = ::Type> instead of Vec<T, A = GlobalAllocator>. That way allocators still don't need to know what type they're allocating and once you're using a specific allocator the rebuild-for-different-but-layout-compatible-type still works.

I'm not sure if this will survive a transformation into/from raw parts unless the programmer carries <T as PickDefaultAllocator>::Type themself, or if they transmute T into U where <T as PickDefaultAllocator>::Type == <U as PickDefaultAllocator>::Type. So I don't think that this is backwards compatible either.

There has been work with single type "slab allocators" of this sort before. CC @joshlf

@Ericson2314 thanks that's a way better performance reason than the one I came up with. I added that as the fifth on the list above.

Looks like the prior art APIs include kmalloc and kmem_cache_alloc which both provide more data than simply layout. Attaching static data to T via traits would work. However, I'm not familiar with kernel allocation patterns. I doubt that dynamic allocation metadata would be generalizable.

[CasperN]

I found this earlier issue that discussed a variant of this idea: #27

@Avi-D-coder and @gnzlbg seemed like they gave it some thought.

@gnzlbg, I'm curious what do you think of the use cases laid out here?

[CasperN]

Actually parameterizing with T will break is the Allocator trait being object safe which was asked for in #83. Assuming that's a bigger priority, this effort needs a different mechanism for passing metadata, i.e. add more fields to Layout. Layout::new is parameterized by T so type specific data can be added unobtrusively. The simplest mechanism is to add TypeId.

[cmazakas]

C++ has typed Allocators and historically, they were a mistake.

They bring more complexity than they save in terms of safety.

Rust's decision to just take a Layout and return a NonNull<[u8]> is the correct one.

[CasperN]

C++ has typed Allocators and historically, they were a mistake. They bring more complexity than they save in terms of safety.

@LeonineKing1199 Can you elaborate on what you think these mistakes and complexities are?

[Lokathor]

well it would probably break the bytemuck try_cast_vec function, for one.

[CasperN]

@Lokathor, backwards compatibility is required so of course the contract should be, 'deallocation with a different type than allocated must not fail if the size and alignment match'. I think I alluded to this in point 3 originally and also in response to @scottmcm. I edited the top comment to reiterate the point explicitly and at the top. Let me know if that is clearer.

[petertodd]

Is there an example of a type aware allocator where something other than size and alignment would be relevant for deallocation? On October 24, 2021 6:02:33 PM EDT, Casper ***@***.***> wrote: ***@***.***, backwards compatibility is required so of course the contract should be, 'deallocation with a different type than allocated must not fail if the size and alignment match'. I think I alluded to this in point 3 originally and also in response to @scottmcm. I edited the top comment to reiterate the point explicitly and at the top. Let me know if that is clearer.

…

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #91 (comment)

[thomcc]

One that uses the typeid as a key to figure out an allocation pool.