Implementing a Basic Address Sanitizer in Rust

Developing robust and safe software is paramount, especially in languages like Rust known for their memory safety guarantees. However, even with Rust's strong type system and borrow checker, certain memory errors can still occur, often due to unsafe code or FFI interactions. This challenge asks you to build a simplified version of an Address Sanitizer (ASan) to detect common memory errors, such as buffer overflows and use-after-free.

Problem Description

Your task is to implement a rudimentary Address Sanitizer in Rust. This sanitizer will monitor memory accesses to detect violations like out-of-bounds reads/writes and use-after-free bugs. For this challenge, we will focus on simulating these errors within a controlled environment and having your sanitizer detect them.

Key Requirements:

1. Memory Allocation Tracking: Your sanitizer needs to keep track of allocated memory regions. This includes the start address, size, and whether the region is currently valid or has been deallocated.
2. Redzones: Implement the concept of "redzones" around allocated memory. A redzone is a small, inaccessible buffer of memory placed before and after the actual user-accessible memory. Accessing these redzones should be flagged as an error.
3. Detection of Out-of-Bounds Access: When a memory access (read or write) occurs, your sanitizer must check if the access falls within the valid user-accessible portion of an allocated memory block, considering the redzones.
4. Detection of Use-After-Free: When memory is deallocated, mark it as inaccessible. Any subsequent access to this deallocated memory should be flagged as an error.
5. Reporting: When a memory error is detected, your sanitizer should print a descriptive error message indicating the type of error, the address accessed, and potentially the location in the code where the error occurred (simulated for this challenge).
6. Integration with unsafe blocks: Your solution will primarily focus on instrumenting memory operations within unsafe blocks to simulate the kind of memory errors that ASan targets.

Expected Behavior:

Your implementation should provide a mechanism to:

• Allocate memory (simulated) and wrap it with redzones.
• Deallocate memory (simulated).
• Perform memory reads and writes through your instrumented wrappers.
• Trigger and detect specific memory errors when they occur.

Important Edge Cases:

• Accessing memory exactly at the boundary of an allocation.
• Accessing memory in the redzones.
• Accessing memory after it has been freed.
• Multiple overlapping or nested allocations (though for simplicity, we might assume non-overlapping for the core logic).

Examples

Example 1: Out-of-Bounds Write

// Simulate a scenario where a program tries to write past the end of an allocated buffer.

// Assume a memory allocation of 10 bytes is requested.
// Your sanitizer will allocate, say, 10 + 2*REDZONE_SIZE bytes.
// The valid user memory is from start_address + REDZONE_SIZE to start_address + REDZONE_SIZE + 10.

// When the program attempts to write to start_address + REDZONE_SIZE + 10 (one byte past the valid end)

Output:

AddressSanitizer: heap-buffer-overflow on write at address 0x12345678
WRITE of size 1 at 0x12345678
    #0 <caller_location> in some_function
    ... (stack trace)

Explanation: The write operation attempted to access memory one byte beyond the allocated user buffer, which falls into the redzone.

Example 2: Use-After-Free

// Simulate a scenario where a program accesses memory after it has been freed.

// Allocate a buffer of 5 bytes.
// Free the buffer.
// Attempt to read from the freed buffer.

Output:

AddressSanitizer: use-after-free on read at address 0x98765432
READ of size 4 at 0x98765432
    #0 <caller_location> in another_function
    ... (stack trace)

Explanation: The read operation attempted to access memory that was previously allocated but has since been deallocated, leading to a use-after-free error.

Example 3: Out-of-Bounds Read (Beginning)

// Simulate reading one byte before the start of an allocated buffer.

// Allocate a buffer of 8 bytes.
// Attempt to read from start_address + REDZONE_SIZE - 1.

Output:

AddressSanitizer: heap-buffer-overflow on read at address 0xabcdef01
READ of size 1 at 0xabcdef01
    #0 <caller_location> in third_function
    ... (stack trace)

Explanation: The read operation attempted to access memory one byte before the start of the valid user buffer, which is part of the pre-redzone.

Constraints

• Simulated Memory: You do not need to implement a full memory allocator. You can use std::alloc::alloc and std::alloc::dealloc from the standard library as your underlying memory management.
• Redzone Size: Assume a fixed REDZONE_SIZE (e.g., 8 or 16 bytes) for simplicity.
• Error Triggering: You will be responsible for writing unsafe Rust code that intentionally triggers these memory errors to test your sanitizer.
• Performance: For this challenge, performance of the sanitizer itself is not a primary concern. Clarity and correctness of error detection are prioritized.
• Stack Trace: Providing a realistic stack trace is beyond the scope of this basic implementation. You can simulate the "caller location" by passing it as a parameter to your instrumented access functions.

Notes

• Consider using a HashMap or similar data structure to store information about allocated memory blocks (address, size, status).
• When you allocate memory, you will need to arrange for the redzones and the user-accessible memory to be contiguous in memory.
• Your instrumented read/write functions will take a pointer, size, and potentially a caller location as arguments. They will perform the checks before attempting the actual memory access (which would happen through unsafe pointer dereferencing).
• Think about how to mark memory as "freed" so that subsequent accesses are caught. A common technique is to overwrite freed memory with a special pattern or to remove it from your tracking structure and flag accesses to previously tracked addresses.
• This challenge is about understanding the principles of memory error detection. You are building a simplified, in-process instrumentation system.