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.
Tock is now on its second major release! Here are some 2.0 highlights, and see the release notes for more detail, or the changelog for the complete set of changes.
- Revamped system call interface.
- Support for 11 new hardware platforms.
- Updated kernel types.
- Many new and improved HILs.
As 2.0 includes many breaking changes, to use the new kernel you will need to
ensure you have updated versions of userspace apps and the various Tock tools.
We recommend if you are using git that you do a git pull, and if you are using
tagged releases be sure to update to the 2.0 release.
Initially, only libtock-c is compatible with Tock 2.0. Work on supporting Tock 2.0 for libtock-rs is under development.
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 that describes the design considerations 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.