Giter Club home page Giter Club logo

tock-bootloader's Introduction

TockOS

tock-ci slack book

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 and type safety. 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.

TockWorld 2024!

Join the community of industry professionals, operating system developers, academics, and interested developers for the annual TockWorld conference. This event in San Diego, CA will take place June 26-28, 2024. Get your tickets today!

Tock 2.x!

Tock is now on its second major release! Tock 2.x includes significant changes from Tock 1.x, including:

  • Revamped system call interface.
  • Support for 11 new hardware platforms.
  • Updated kernel types.
  • Many new and improved HILs.

For a summary of the latest new features and improvements, check out the changelog.

Learn More

How would you like to get started?

Learn How Tock Works

Tock is documented in the Tock Book. Read through the guides there to learn about the overview and design of Tock, its implementation, and much more.

Use Tock

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.

A book on how to use Tock with the micro:bit v2 and Raspberry Pi Pico boards is Getting Started with Secure Embedded Systems.

Find example applications that run on top of the Tock kernel written in both Rust and C.

Develop Tock

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.

Keep Up To Date

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.

Code of Conduct

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.

Cite this Project

Tock was presented at SOSP'17

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 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},
}

There is also a paper on the Tock security model. The threat model documentation in the docs/ folder is the source of truth for the current Tock threat model, but this paper represents a snapshot of the reasoning behind the Tock threat model and details how it compares to those in similar embedded OSes.

@inproceedings{10.1145/3517208.3523752,
	author = {Ayers, Hudson and Dutta, Prabal and Levis, Philip and Levy, Amit and Pannuto, Pat and Van Why, Johnathan and Watson, Jean-Luc},
	title = {Tiered Trust for Useful Embedded Systems Security},
	year = {2022},
	isbn = {9781450392556},
	publisher = {Association for Computing Machinery},
	address = {New York, NY, USA},
	url = {https://doi.org/10.1145/3517208.3523752},
	doi = {10.1145/3517208.3523752},
	booktitle = {Proceedings of the 15th European Workshop on Systems Security},
	pages = {15–21},
	numpages = {7},
	keywords = {security, embedded systems, operating systems, IoT},
	location = {Rennes, France},
	series = {EuroSec '22}
}

License

Licensed under either of

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.

tock-bootloader's People

Contributors

alevy avatar alexandruradovici avatar bradjc avatar brghena avatar gentooza avatar mateibarbu19 avatar ppannuto avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

tock-bootloader's Issues

Support "USB-only" nRF52 boards

Typically our bootloaders require an FTDI chip to do serial over USB so that the bootloader running on the chip only requires a serial interface. Since MCUs sometimes have USB hardware, It has always seemed reasonable to omit the FTDI chip and just communicate with the USB peripheral on the MCU directly. In particular, the Arduino Nano 33 relies on having a USB bootloader on the chip itself.

Help Wanted: Make kernel location variable

Right now, the kernel location is fixed at 0x10000. Ideally, this wouldn't be fixed in case a platform wants to put its kernel at a different address.

fn jump(&self) {
unsafe {
asm!(
".syntax unified \n\
ldr r0, =0x10000 // The address of the payload's .vectors \n\
ldr r1, =0xe000ed08 // The address of the VTOR register (0xE000E000(SCS) + 0xD00(SCB) + 0x8(VTOR)) \n\
str r0, [r1] // Move the payload's VT address into the VTOR register \n\
ldr r1, [r0] // Move the payload's initial SP into r1 \n\
mov sp, r1 // Set our SP to that \n\
ldr r0, [r0, #4] // Load the payload's ENTRY into r0 \n\
bx r0 // Whoopee"
);
}
}
}

I don't think this would be particularly hard, I just don't know how to do it.

Instructions

The instructions tell you to go to

boards/

but the only subdirectory is

boards/hail-bootloader

Does this work for imix? If hail is the only board supported then the instructions should say so explicitly.

Tracking Issue: nrf5x support

This may need to split to nrf51 and 52 in the future, but hopefully the bootloader is minimal enough that much/most can be shared.

nrf52dk bootloader

What is necessary to use the bootloader with the nrf52dk USB debugger?

Bootloader cannot update itself

Although the bootloader can program the kernel and any application over serial, it cannot update its own code, since it is running from flash.

If the bootloader code relocates into RAM, it would be possible to arbitrarily overwrite its flash image. Thus, the bootloader could update itself.

I think the relocation step could be implemented simply by changing the linker script, so that all code sections are between _srelocate and _erelocate. The startup code will take care of the rest.

The only remaining item would be to add a corresponding command to tockloader.

Maybe this is a feature we don't actually want? It would allow a board to be bricked by a bad bootloader image (assuming the developer doesn't have a JLink). For a developer with only serial port access, the choice is either 1. a bad bootloader update could brick them, or 2. they are stuck with whatever version of the bootloader they started with.

Personally, I think 2. is the worse case, but maybe others feel differently. Thoughts?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.