Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MIR: Add mir_alloc_static command to better track mutable statics #1982

Open
RyanGlScott opened this issue Nov 13, 2023 · 0 comments
Open

MIR: Add mir_alloc_static command to better track mutable statics #1982

RyanGlScott opened this issue Nov 13, 2023 · 0 comments
Labels
subsystem: crucible-mir Issues related to Rust verification with crucible-mir and/or mir-json tech debt Issues that document or involve technical debt type: enhancement Issues describing an improvement to an existing feature or capability usability An issue that impedes efficient understanding and use

Comments

@RyanGlScott
Copy link
Contributor

After #1959 lands, in order to use a MIR compositional override as part of verifying a Rust program that defines a mutable static item, you must specify what its value is in the override's postcondition. This proves to be quite burdensome in practice, as most overrides will have nothing to do at all with mutable static variables. This is especially true when dealing with code that involves the standard Rust libraries, as the library internals define these four mutable static items, which all overrides must now explicitly specify:

  • std::panicking::panic_count::LOCAL_PANIC_COUNT::__getit::VAL
  • std::panicking::panic_count::LOCAL_PANIC_COUNT::__getit::STATE
  • std::sync::remutex::current_thread_unique_ptr::X::__getit::VAL
  • std::sync::remutex::current_thread_unique_ptr::X::__getit::STATE

A much nicer alternative would be to track the mutable static items that are specifically used within a particular function and allow the function's specification to leave all other mutable static items unspecified. This is exactly the approach that the SAW LLVM backend uses. In order to use a mutable global variable in an LLVM specification, the preconditions must explicitly indicate this using the llvm_alloc_global command. When that specification is used as a compositional override, any mutable global variables that were:

  1. Allocated with llvm_alloc_global in the preconditions
  2. Lack corresponding llvm_points_to statements in the postconditions

Will have their underlying memory invalidated. If the LLVM function doesn't make use of the invalidated mutable globals, this is not a problem, but crucible-llvm will fail to simulate any function that does make use of invalidated globals.

This issue proposes re-engineering the design of the SAW MIR backend to support tracking mutable statics in the way that the LLVM backend does. More specifically, we will need to:

While this is primarily motivated by the MIR backend's treatment of mutable static items, the same memory invalidation approach would also work for local mutable allocations (i.e., things allocated with mir_alloc_mut).

@RyanGlScott RyanGlScott added type: enhancement Issues describing an improvement to an existing feature or capability usability An issue that impedes efficient understanding and use tech debt Issues that document or involve technical debt subsystem: crucible-mir Issues related to Rust verification with crucible-mir and/or mir-json labels Nov 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
subsystem: crucible-mir Issues related to Rust verification with crucible-mir and/or mir-json tech debt Issues that document or involve technical debt type: enhancement Issues describing an improvement to an existing feature or capability usability An issue that impedes efficient understanding and use
Projects
None yet
Development

No branches or pull requests

1 participant