I'm writing some Rust code for the UEFI environment. I receive a raw pointer from the firmware allocated on UEFI heap. I want to be able to manage this pointer in an RAII way. I've already got a custom global allocator in Rust (written using EfiAllcator trait; I know it's not the latest but I'm on old nightlies) which operates on top of the same UEFI heap. So what I was looking for is a way to wrap this raw pointer into something like Box such that when this wrapper goes out of scope my custom allocator automatically hands the pointer back to UEFI heap's free routine and the pointer is freed. I looked at Box's documentation, but it's non committal about being able to take care of non-Box-originating pointers like this. Is there any alternative which I can use or will I have to write something of my own for this purpose?
Maybe look into scopeguard::guard - Rust. But your own RAII wrapper should be fairly trivial to write as well.
I may be missing something, but wouldn't it be enough to "simply" impl Drop for MyUefiPointerWrapper?
the Drop trait is exactly for situations where you want to run a "destructor".
Or are Drop's guarantees not strong enough for this situation? (after all, since the great leakpocalyse of 2016, memory leakls are memory safe, Drop isn't guaranteed to always run, just "almost always")
Vitaly's suggestion looks like the less-hassle version though; it's basically a mostly pre-implemented version of writing your own wrapper.
So your custom allocator makes it so that Box is backed by a UEFI heap, and your raw pointer comes from that same heap? If that's so then perhaps you could simply do Box::from_raw on the pointer to make a proper Box out of it.
This is a bad practice by default since you need to ensure that the same allocator that creates something is the one that deletes it, and on most platforms 1) Rust might not use the same allocator as C/the underlying system and 2) even if Rust is using the system allocator, environments with dynamic linking might have multiple system allocators linked in to different libraries. But if your case involves everything being static linked and using a single allocator, then you can probably get away with it. Might wanna double-check my logic there in case I'm wrong though.
Even if the same allocator is used by Box and whatever allocated the ptr, Box doesn’t specify how it interacts with the allocator. As it happens, I don’t think it does anything surprising today. But, one could run afoul of some future changes. One can practically think of Box itself as being a specific allocator, at least as it now stands.
That’s essentially the warning that @gurry found in the docs there.
Yes, my situation is exactly as @FenrirWolf described. My Boxs are -- or ought to be -- coming from the same heap as this raw pointer thanks to my custom allocator. So I too felt Box should just work, but wanted to confirm. Based on all your comments now, I'm gonna write something of my own and make use of scopeguard internally maybe. Thanks for the suggestions guys 
.