Comments (3)
The unlock function uses munlock
internally (with the corresponding mlock
call, on POSIX platforms). Since mlock
prevents a region of memory to be paged to a swap area, munlock
in turn allows the memory to yet again be paged.
As you surely know, Rust itself has a very clear definition of memory safety; it prevents data races & segmentation faults (i.e. accessing memory that is not owned by the executing code). The unlock
function does not violate these principles — paged memory can still be accessed, and does not cause a segmentation fault.
It may not be safe in the general sense (e.g. causing a password/token to be paged to disk), but that is not translatable to Rust's semantics of safe (which unsafe
is an indicator of).
Finally, both munlock
and VirtualUnlock
validate their input, so, e.g, passing in a null pointer (or any pointer for that matter) is still memory safe.
If I'm missing something, or have any misconception regarding the semantics, please feel free to correct me, but from my understanding this is compliant with Rust's rules of memory safety.
from region-rs.
It's tricky.. As I understand it, there is only a locked bit per page that acts like a static mut
, so if you mlock
two allocations that lie in the same page, then the second mlock
has no effect, and munlock
ing either one unlocks both. We thus cannot claim the locked bit state to be well defined. Afaik, we cannot read this locked bit, so maybe this UB cannot propagate, but still..
A priori, I'd expect mlock
and munlock
to be regarded as intrinsic-like unsafe tools, which users never touch from safe code. Instead, safe code should invoke them via a custom allocator, either an arena or jemalloc distinct pool, which then returns allocations in locked pages. I suspect mmap
gives less bad but still technically unsafe semantics because afaik it only allocates whole pages. I've never thought much about this however..
In practice, I suspect you typically only have limited secret material known when processes start so you mlock
a couple allocations, which you never munlock
, but instead just let the kernel clean up when your process terminates. There is no UB here from Rust's perspective, and anything sensitive stays locked, but some other allocation unnecessarily and randomly fall into the locked page.
from region-rs.
@darfink Thanks! I can see how your explanation makes sense.
I think it's a tricky question though, because the entire point of locking memory is to avoid letting some critical data be swapped out, and having functions like munlock
be safe means that dangling pointers could lead to it being swapped out. So while there's no UB, there is a hazard involving dangling raw pointers, which is the kind of thing Rust's safety normally protects against.
One way to think about it would be to say that the OS swapping pages out of memory constitutes a form of I/O. That's how someone storing sensitive data in memory and using mlock
to prevent it from being swapped out for security reasons might think about it. In that case, munlock
could be thought of as a request to the OS to do I/O on the referenced memory, which is effectively dereferencing the memory -- the OS has to read the memory to swap it out. With that interpretation, munlock
should be unsafe, because it's "reading" from raw pointers. Does that make sense?
from region-rs.
Related Issues (12)
- How to handle PAGE_GUARD on Windows?
- Question: How to use this in multi-threaded environment? HOT 1
- Support for AArch64- and Linux-specific protection attributes HOT 1
- `QueryIter` not found in `os` HOT 3
- Please make the name/description of the region available
- cumbersome when region::protect deals with Elf64_Phdr.p_flags HOT 4
- Locking libc version makes it incompatible HOT 3
- query_code test fails on Fedora Rawhide HOT 3
- protect::protect fails on non-x86 architectures HOT 4
- Feature Request: Add support for OpenBSD HOT 17
- Why is LockGuard::release unsafe? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from region-rs.