MIRI Integration Status

[bitboom]

MIRI found bugs

1. Memory Leak in Multi-Level Page Table

• Problem: Sub Tables allocated during the map() in RMM's Page Table were not deallocated during the unmap() when entries were cleared.
• Proposed Solution: Applying reference count to page tables to deallocate sub tables if they are no longer in use.

Affected part

• rmi_granule_delegate/undelegate
• rmi_data_create/unknown
• rmi_realm_create/destroy
• rmi_rec_create/destroy
• host::copy_*

Error Message

$ cargo miri test rmi::gpt::test::rmi_granule_delegate

error: memory leaked: alloc56894755 (Rust heap, size: 4096, align: 4096), allocated here:
   --> /home/sangwan/.rustup/toolchains/nightly-2024-04-21-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/alloc.rs:100:9
    |
100 |         __rust_alloc(layout.size(), layout.align())
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: BACKTRACE:
    = note: inside `alloc::alloc::alloc` at /home/sangwan/.rustup/toolchains/nightly-2024-04-21-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/alloc.rs:100:9: 100:52
    = note: inside `<vmsa::page_table::DefaultMemAlloc as vmsa::page_table::MemAlloc>::allocate` at /home/sangwan/islet/lib/vmsa/src/page_table.rs:63:9: 63:36
    = note: inside `vmsa::page_table::PageTable::<vmsa::address::VirtAddr, mm::page_table::L3Table, mm::page_table::entry::Entry, 512>::new_in` at /home/sangwan/islet/lib/vmsa/src/page_table.rs:159:13: 159:92
    = note: inside `<vmsa::page_table::PageTable<vmsa::address::VirtAddr, mm::page_table::L2Table, mm::page_table::entry::Entry, 512> as vmsa::page_table::PageTableMethods<vmsa::address::VirtAddr, mm::page_table::L2Table, mm::page_table::entry::Entry, 512>>::set_page::<mm::page::BasePageSize>` at /home/sangwan/islet/lib/vmsa/src/page_table.rs:392:25: 394:26
    = note: inside `<vmsa::page_table::PageTable<vmsa::address::VirtAddr, mm::page_table::L1Table, mm::page_table::entry::Entry, 512> as vmsa::page_table::PageTableMethods<vmsa::address::VirtAddr, mm::page_table::L1Table, mm::page_table::entry::Entry, 512>>::set_page::<mm::page::BasePageSize>` at /home/sangwan/islet/lib/vmsa/src/page_table.rs:400:13: 400:50
    = note: inside `<vmsa::page_table::PageTable<vmsa::address::VirtAddr, mm::page_table::L1Table, mm::page_table::entry::Entry, 512> as vmsa::page_table::PageTableMethods<vmsa::address::VirtAddr, mm::page_table::L1Table, mm::page_table::entry::Entry, 512>>::set_pages::<mm::page::BasePageSize>` at /home/sangwan/islet/lib/vmsa/src/page_table.rs:215:19: 215:

---

MIRI Integration Challenges

1. Handling Provenance Issues with for Host-Provided Memory

• Problem: When using MIRI to test Rust code, the "No provenance" error can occur 1) during operations like core::ptr::write or 2) when converting externally allocated memory into specific Rust objects. This happens because the memory addresses, not allocated by RMM, lack the required provenance that MIRI enforces.
• Limitation: Currently, MIRI does not allow the disabling of provenance checks. Additionally, Rust does not natively support allocating memory at specific addresses, further complicating this scenario.
• Proposed Alternative: Instead of using externally provided memory addresses directly, simulate these addresses by allocating memory within RMM’s managed space and treating it as if it were the external memory. This approach avoids provenance issues while still allowing the use of MIRI for testing.