-
Notifications
You must be signed in to change notification settings - Fork 4
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
Stack overflow soundness #11
Comments
We should be able to address this without runtime checks by flipping the layout of the program memory as explained in this blog post. Under the hood this requires running the linker twice but from the point of the view of the application author they only have install a linker wrapper and use that linker instead of rustc's lld. We can set the linker wrapper as the default linker in the application template and even make the linking of applications fail if they don't use that specific linker wrapper. With that in place stack overflows will make one of the exception handlers ( |
linking now must be done using the `flip-lld` linker wrapper (this is the default for all the examples). This linker wrapper flips the standard memory layout of programs so that the stack cannot overwrite unrelated memory when it grows in an unbounded fashion. More details can be found in the blog post: https://blog.japaric.io/stack-overflow-protection/ Stack overflows will now trigger a "data abort" (hardware) exception when memory is exhausted. The handler for this exception will print a message to the console (using the `Serial` API) and then reboot the SoC. An example has been added to demo this behavior. closes #11
It would be nice to have some sound way of handling stack overflow. This is presently an unsolved upstream problem for non-x86/x86_64 platforms:
rust-lang/rust#43241
It seems like the best solution is to implement stack probes for ARM in upstream Rust.
The text was updated successfully, but these errors were encountered: