Tock is an embedded operating system designed for running multiple concurrent, mutually distrustful applications on Cortex-M and RISC-V based embedded platforms. Tock's design centers around protection, both from potentially malicious applications and from device drivers. Tock uses two mechanisms to protect different components of the operating system. First, the kernel and device drivers are written in Rust, a systems programming language that provides compile-time memory safety, type safety and strict aliasing. Tock uses Rust to protect the kernel (e.g. the scheduler and hardware abstraction layer) from platform specific device drivers as well as isolate device drivers from each other. Second, Tock uses memory protection units to isolate applications from each other and the kernel.
Note! Tock is currently switching from version 1.6 to 2.0 which includes breaking changes in the syscall interface. This means applications (for example from libtock-c) need to match the updated syscall interface. If the application does not match the kernel interface the app will likely fault very quickly.
The following combinations between kernel and userspace should work:
- Tock on master, with libtock-c on master.
- Tock on release v1.6, libtock-c on v1.6.
- Tock on release v1.6, libtock-rs on master.
Note, libtock-rs does not currently support Tock 2.0, but will before 2.0 is released.
Tock will continue to make this easier as we work towards the 2.0 release.
How would you like to get started?
Tock is documented in the doc folder. Read through the guides there to learn about the overview and design of Tock, its implementation, and much more.
Follow our getting started guide to set up your system to compile Tock.
Head to the hardware page to learn about the hardware platforms Tock supports. Also check out the Tock Book for a step-by-step introduction to getting Tock up and running.
Find example applications that run on top of the Tock kernel written in both Rust and C.
Read our getting started guide to get the correct
version of the Rust compiler, then look through the /kernel
, /capsules
,
/chips
, and /boards
directories. There are also generated source code
docs.
We encourage contributions back to Tock and are happy to accept pull requests for anything from small documentation fixes to whole new platforms. For details, check out our Contributing Guide. To get started, please do not hesitate to submit a PR. We'll happily guide you through any needed changes.
Check out the blog where the Talking Tock post series highlights what's new in Tock. Also, follow @talkingtock on Twitter.
You can also browse our email group and our Slack to see discussions on Tock development.
The Tock project adheres to the Rust Code of Conduct.
All contributors, community members, and visitors are expected to familiarize themselves with the Code of Conduct and to follow these standards in all Tock-affiliated environments, which includes but is not limited to repositories, chats, and meetup events. For moderation issues, please contact members of the @tock/core-wg.
Amit Levy, Bradford Campbell, Branden Ghena, Daniel B. Giffin, Pat Pannuto, Prabal Dutta, and Philip Levis. 2017. Multiprogramming a 64kB Computer Safely and Efficiently. In Proceedings of the 26th Symposium on Operating Systems Principles (SOSP ’17). Association for Computing Machinery, New York, NY, USA, 234–251. DOI: https://doi.org/10.1145/3132747.3132786
Bibtex
@inproceedings{levy17multiprogramming, title = {Multiprogramming a 64kB Computer Safely and Efficiently}, booktitle = {Proceedings of the 26th Symposium on Operating Systems Principles}, series = {SOSP'17}, year = {2017}, month = {10}, isbn = {978-1-4503-5085-3}, location = {Shanghai, China}, pages = {234--251}, numpages = {18}, url = {http://doi.acm.org/10.1145/3132747.3132786}, doi = {10.1145/3132747.3132786}, acmid = {3132786}, publisher = {ACM}, address = {New York, NY, USA}, conference-url = {https://www.sigops.org/sosp/sosp17/}, author = {Levy, Amit and Campbell, Bradford and Ghena, Branden and Giffin, Daniel B. and Pannuto, Pat and Dutta, Prabal and Levis, Philip}, }
This is the primary paper the describes the design consdierations of Tock.
Other Tock-related papers
There are also two shorter papers that look at potential limitations of the Rust language for embedded software development. The earlier PLOS paper lays out challenges and the later APSys paper lays out potential solutions. Some persons describing work on programming languages and type theory may benefit from these references, but generally, most work should cite the SOSP paper above.
@inproceedings{levy17rustkernel, title = {The Case for Writing a Kernel in Rust}, booktitle = {Proceedings of the 8th Asia-Pacific Workshop on Systems}, series = {APSys '17}, year = {2017}, month = {9}, isbn = {978-1-4503-5197-3}, location = {Mumbai, India}, pages = {1:1--1:7}, articleno = {1}, numpages = {7}, url = {http://doi.acm.org/10.1145/3124680.3124717}, doi = {10.1145/3124680.3124717}, acmid = {3124717}, publisher = {ACM}, address = {New York, NY, USA}, conference-url = {https://www.cse.iitb.ac.in/~apsys2017/}, author = {Levy, Amit and Campbell, Bradford and Ghena, Branden and Pannuto, Pat and Dutta, Prabal and Levis, Philip}, }
@inproceedings{levy15ownership, title = {Ownership is Theft: Experiences Building an Embedded {OS} in {R}ust}, booktitle = {Proceedings of the 8th Workshop on Programming Languages and Operating Systems}, series = {PLOS 2015}, year = {2015}, month = {10}, isbn = {978-1-4503-3942-1}, doi = {10.1145/2818302.2818306}, url = {http://dx.doi.org/10.1145/2818302.2818306}, location = {Monterey, CA}, publisher = {ACM}, address = {New York, NY, USA}, conference-url = {http://plosworkshop.org/2015/}, author = {Levy, Amit and Andersen, Michael P and Campbell, Bradford and Culler, David and Dutta, Prabal and Ghena, Branden and Levis, Philip and Pannuto, Pat}, }
Licensed under either of
- Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
- MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)
at your option.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.