struct X {
y: Y
}
impl X {
fn y(&self) -> &Y { &self.y }
}
This defines an aggregate type containing a field y of type Y directly (not as a separate heap object). Then we define a getter method that returns the field by reference. Crucially, the Rust compiler will verify that all callers of the getter prevent the returned reference from outliving the X object. It compiles down to what you'd expect a C compiler to produce (pointer addition) with no space or time overhead.
Let's look into this a bit more deeply. But, since this is The Internet, first a pre-emptive statement.
Things not claimed in this blog post
To make things easier for forum discussers who have strong opinions but have hard time reading entire articles, here is a list of things that are not claimed. I repeat: not claimed.
- that [other language] is as safe as Rust (it is most likely not)
- that you should use [other language] instead of Rust
- that you should use Rust instead of [other language]
- that [other language] is safe out of the box (it probably is not)
- security feature X of language Y will prevent all bugs of type Z (it does not)
To business
Plain C code corresponding to the setup above is roughly the following:
struct foo {
int x;
};
struct bar {
struct foo f;
};
A simple function that demonstrates the bug is the following:
int main(int argc, char **argv) {
struct foo *f;
struct bar *expiring = malloc(sizeof(struct bar));
f = &expiring->f;
free(expiring);
do_something(f);
return 0;
}
This uses an obviously invalid pointer in a function call. Neither GCC nor Clang warns about this when compiling. Scan-build, however, does detect the bug:
expired.c:23:3: warning: Use of memory after it is freed
do_something(f);
^~~~~~~~~~~~~~~~~
1 warning generated.
scan-build: 1 bug found.
Address sanitizer also detects the invalid access operation inside do_something. Things get more interesting if we change the function so that expiring is on the stack instead of the heap.
int main(int argc, char **argv) {
struct foo *b;
{
struct bar expiring;
b = &expiring.f;
}
do_something(b);
return 0;
}
This one is not detected at all. Neither GCC, Clang, Scan-build, Asan, CppCheck nor Valgrind see anything wrong with this. Yet this seems so simple and obvious that it should be detectable automatically.
Recently this has become possible with Address sanitizer. It grew a new argument -fsanitize-address-use-after-scope, which checks for exactly this and finds the bug effortlessly:
==10717==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffe5d0c1920 at pc 0x00000050767f bp 0x7ffe5d0c18a0 sp 0x7ffe5d0c1898
This requires, of course, a run of the program that executes this code path. It would be nice to have this in a static analyzer so it could be found in even more cases (there is already a bug report for this for scan-build).
In conclusion
The security features of Rust are great. However many of them (not all, but many) that were unique to Rust are now possible in other languages as well. If you are managing a project in C or C++ and you are not using asan + scan-build + other error checkers on your code, you should use them all and fix the issues detected. Do it even if you intend to rewrite your code in Rust, Go or any other language. Do it now! There is no excuse.
