1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235
//! Global Allocator Bridge
//!
//! This module provides a bridge between the global-allocator interface of
//! the rust standard library and the allocators of this crate. The stabilized
//! interface of the rust compiler and standard-library to the global allocator
//! is provided by the `core::alloc::GlobalAlloc` trait and the
//! `global_allocator` attribute. The types provided by this module implement
//! this trait and can be used to register a global allocator.
//!
//! Only one crate in every dependency graph can use the `global_allocator`
//! attribute to mark one static variable as the global allocator of the entire
//! application. The type of it must implement `GlobalAlloc`. Note that this
//! attribute can only be used in the crate-root, not in sub-modules.
//!
//! UEFI is, however, not a natural fit for the global-allocator trait. On UEFI
//! systems, access to all system APIs is done through the system table, which
//! is passed as argument to the application entry-point. Therefore, it is up
//! to the implementor of the entry-point to set up the global state inherent
//! to rust's global allocator.
//!
//! # Examples
//!
//! The following UEFI application simply registers an allocator with its
//! system-table and then invokes `uefi_run()`. The latter can then operate
//! under the assumption that an allocator is available and ready. Once the
//! function returns, the allocator is automatically torn down.
//!
//! This is a typical use of the `r-efi-alloc` crate. Only applications that
//! actually exit the boot-services, or access UEFI outside of regular UEFI
//! application and driver environments will have to use the custom allocator
//! interfaces.
//!
//! ```ignore
//! #![no_main]
//! #![no_std]
//!
//! use r_efi::efi;
//! use r_efi_alloc::{alloc::Allocator, global::Bridge};
//!
//! #[global_allocator]
//! static GLOBAL_ALLOCATOR: Bridge = Bridge::new();
//!
//! #[no_mangle]
//! pub extern "C" fn efi_main(
//! h: efi::Handle,
//! st: *mut efi::SystemTable,
//! ) -> efi::Status {
//! unsafe {
//! let mut allocator = Allocator::from_system_table(st, efi::LOADER_DATA);
//! let _attachment = GLOBAL_ALLOCATOR.attach(&mut allocator);
//!
//! efi_run(h, st)
//! }
//! }
//!
//! pub fn efi_run(h: efi::Handle, st: *mut efi::SystemTable) -> efi::Status {
//! ...
//! }
//! ```
use core::sync::atomic;
/// Bridge for Global Allocators
///
/// This bridge connects static allocator variables to the dynamic UEFI
/// allocator interfaces. The bridge object implements the `GlobalAlloc`
/// interface and can thus be marked as `global_allocator`.
///
/// The need for a bridge arises from the fact that UEFI requires access to
/// the system-table to allocate memory, and the system-table is only available
/// as argument to the entry-point. Hence, this bridge represents a dynamic
/// link between the global allocator and a runtime allocator created by the
/// application.
///
/// The main API of the bridge is the `attach()` function, which allows to
/// attach an allocator to the bridge, which is thereon used for allocations.
/// Only a single allocator can be attached to a bridge at a time, and any
/// global allocations will fail if no allocator is attached.
///
/// The `attach()` operation returns an object that represents the attachment.
/// To release it, the attachment object has to be dropped. Note that the
/// caller must ensure that any global allocator is released before an
/// allocator attachment is released.
pub struct Bridge {
attachment: atomic::AtomicPtr<crate::alloc::Allocator>,
}
/// Bridge Attachment
///
/// This type represents the attachment of an allocator to a bridge. It is
/// returned by the `attach()` operation of a bridge. This type has no exposed
/// API other than a custom `drop()` implementation, which releases the
/// attachment.
pub struct Attachment<'alloc, 'bridge> {
allocator: &'alloc mut crate::alloc::Allocator,
bridge: &'bridge Bridge,
}
impl Bridge {
/// Create Bridge
///
/// The Bridge type represents the global allocator. Since the latter
/// cannot be instantiated at compile-time (on UEFI the system-table
/// address can only be resolved at runtime, since it is passed as argument
/// to the entry point), it is implemented as a bridge between the actual
/// allocator object and the global allocator. By default, the bridge
/// object has no allocator linked. Any allocation requests will thusly
/// yield an allocation error.
///
/// To make use of a bridge, you have to instantiate an allocator object
/// and attach it via the `attach()` method.
///
/// You can create as many bridges as you like. However, to mark a bridge
/// as global allocator, you have to make it a global, static variable and
/// annotate it with `#[global_allocator]`. Only one such variable is
/// allowed to exist in any crate tree, and it must be declared in the root
/// module of a given crate.
pub const fn new() -> Bridge {
Bridge {
attachment: atomic::AtomicPtr::new(core::ptr::null_mut()),
}
}
unsafe fn raw_attach(&self, ptr: *mut crate::alloc::Allocator) -> Option<()> {
// Set @ptr as the attachment on this bridge. This only succeeds if
// there is not already an attachment set.
// We use a compare_exchange() to change the attachment if it was NULL.
// We use Release semantics, so any stores to your allocator are
// visible once the attachment is written. On error, no ordering
// guarantees are given, since this interface is not meant to be a
// programmatic query.
// Note that the Release pairs with the Acquire in the GlobalAlloc
// trait below.
//
// This interface is unsafe since the caller must guarantee to detach
// the bridge before it is destroyed. There are no runtime guarantees
// given by this interface, it is all left to the caller.
let p = self.attachment.compare_exchange(
core::ptr::null_mut(),
ptr,
atomic::Ordering::Release,
atomic::Ordering::Relaxed,
);
if p.is_ok() {
Some(())
} else {
None
}
}
unsafe fn raw_detach(&self, ptr: *mut crate::alloc::Allocator) {
// Detach @ptr from this bridge. The caller must guarantee @ptr is
// already attached to the bridge. This function will panic if @ptr is
// not the current attachment.
//
// We use compare_exchange() to replace the old attachment with NULL.
// If it was not NULL, we panic. No ordering guarantees are required,
// since there is no dependent state.
let p = self.attachment.compare_exchange(
ptr,
core::ptr::null_mut(),
atomic::Ordering::Relaxed,
atomic::Ordering::Relaxed,
);
assert!(p.is_ok());
}
/// Attach an allocator
///
/// This attaches the allocator given as @allocator to the bridge. If there
/// is an allocator attached already, this will yield `None`. Otherwise, an
/// attachment is returned that represents this link. Dropping the
/// attachment will detach the allocator from the bridge.
///
/// As long as an allocator is attached to a bridge, allocations through
/// this bridge (via rust's `GlobalAlloc` trait) will be served by this
/// allocator.
///
/// This is an unsafe interface. It is the caller's responsibility to
/// guarantee that the attachment survives all outstanding allocations.
/// That is, any allocated memory must be released before detaching the
/// allocator.
pub unsafe fn attach<'alloc, 'bridge>(
&'bridge self,
allocator: &'alloc mut crate::alloc::Allocator,
) -> Option<Attachment<'alloc, 'bridge>> {
match self.raw_attach(allocator) {
None => None,
Some(()) => Some(Attachment {
allocator: allocator,
bridge: self,
}),
}
}
}
impl<'alloc, 'bridge> Drop for Attachment<'alloc, 'bridge> {
fn drop(&mut self) {
unsafe {
self.bridge.raw_detach(self.allocator);
}
}
}
// This implements GlobalAlloc for our bridge. This trait is used by the rust
// ecosystem to serve global memory allocations. For this to work, you must
// have a bridge as static variable annotated as `#[global_allocator]`.
//
// We simply forward all allocation requests to the attached allocator. If the
// allocator is NULL, we fail the allocations.
//
// Note that the bridge interface must guarantee that an attachment survives
// all allocations. That is, you must drop/deallocate all memory before
// dropping your attachment. See the description of the bridge interface for
// details.
unsafe impl core::alloc::GlobalAlloc for Bridge {
unsafe fn alloc(&self, layout: core::alloc::Layout) -> *mut u8 {
let allocator = self.attachment.load(atomic::Ordering::Acquire);
if allocator.is_null() {
return core::ptr::null_mut();
}
(&*allocator).alloc(layout)
}
unsafe fn dealloc(&self, ptr: *mut u8, layout: core::alloc::Layout) {
let allocator = self.attachment.load(atomic::Ordering::Acquire);
assert!(!allocator.is_null());
(&*allocator).dealloc(ptr, layout)
}
}