[comradelion]

One of the Tock maintainers here, happy to answer any questions.

For some context, Tock has been around for a number of years now (we first built it in 2015). Beyond it's intended original purpose (naval gazing academic research) it runs the Chromebook embedded controller, has similar other similar applicatioms in data center root-of-trust, Microsoft's Pluton (rumor has it, for some future version anyway), and others.

[hollerith]

I was unimpressed after reading Tock's home page (and I think I read it all), but then I was quite impressed by your "runs the Chromebook embedded controller" (because the ChromeOS team seems to me to be great at security).

I humbly suggest adding that to the home page (being careful to mention that the ChromiumOS EC repo has not been updated to reflect that fact and to mention that before about a year ago, something else ran the EC).

[sillywalk]

I thought the Chromebook embedded controllers run Zephyr?

[comradelion]

Nope. It used to be a home baked solution that was totally unrelated to (and pre-dates) Zephyr. I believe that is the one that is still in the ChromiumOS EC repo, but for the last year or so, it's a Tock-based system.

[sillywalk]

Do you have a link for the Tock as the Chrome EC OS? My google-foo couldn't find anything.

"Starting roughly in July of 2021, Chromebooks switched from the original Google Chrome EC to an application based on the Zephyr Project RTOS."[0]

[0] https://chromium.googlesource.com/chromiumos/platform/ec/+/H...

EDIT: looks like there's something about Tock running on OpenTitan

https://opentitan.org/book/sw/device/index.html

[comradelion]

Oh my apologies! I hadn't known about that intermediate version.

I don't know of a public announcement. Tock's license is acknowledged in Chromebook's licenses and those involved in Tock know simply because that team talks to us (a few of us interned on that team back when we were PhD students to help the effort at various stages as well).

It's not a secret, but it's also not something that seems to be high on anyone's todo list over there to announce.

[sillywalk]

It looks like Tock is also being used by Google for their security chips/dongles OpenTitan and OpenSK.

[comradelion]

Correction, it's not the EC that runs Tock, but rather the GSC (the creatively named Google Security Chip). It used to run a system called Cr50 while recent versions run Ti50, which is Tock-based.

[nevi-me]

What are practical applications that I can build for home use on Tock, using either ESP32-C3 or NRF52840 dongle?

[comradelion]

In principle many things, but you're mostly restricted by what you can meaningfully physically build with off the shelf parts. Prototyping with a bunch of wires on a bread board is one thing... Sticking that on your wall is another. And most off the shelf dev kits have very few useful sensors/actuators on board.

The cannonical thing is an environment sensor (so a temperature et al sensor). Unfortunately, often a larger HVAC system will integrate with sensors through some proprietary protocol (even Thread based systems like Nest don't necessarily work with just any thread-based sensor, but you could of course hack something with Home assistant).

One of the maintainers has been using it on the side for a plan monitoring system.

All of these require some sensors beyond just the dev kit, which are typically pretty bare bones.

You can build a two factor auth device with the nrf52840 dongle (OpenSK is built with Tock), which requires basically no extra peripherals.

I've used the nrf52840dk to control a garage door, which similarly only need a couple wires.

[fanf2]

How does Tock compare to Oxide’s Hubris?

[comradelion]

Note bcantrill's comment below for corrections of my misstatements here.

Oxide was involved with Tock before building Hubris. They are similar in some ways with somewhat different "visions" for the end use case. Hubris compiles all "applications" into the "kernel", and relies exclusively on the type system for isolation---in this sense it is a much more traditional RTOS, just written in Rust (and well designed!). Whereas Tock targets applications that are not just in Rust, and may be dynamically load/replaced/removed separately from the kernel---in this sense it is much more similar to a traditional desktop/server OS but designed for significantly lower resourced settings. This also makes Tock more robust to applications that are actually untrusted or unreliable.

There is also of course a difference in development and evolution. Hubris is developed by Oxide and released open source, while Tock is more community based and, thus, more open to supporting a variety of use cases. This is both bad and good. If your use case is exactly Oxide's use case, it's likely Hubris is better than Tock (there is just no design decision baggage for other use cases). If you're use case is a bit different, Tock starts to be more appropriate.

A side note that I think the Hubris-Tock relationship is a real positive case for open source development. Oxide was very transparent and forthcoming when they decided to switch away and offered a lot of useful feedback. I hope they took some ideas from Tock and I think we took some ideas from following Hubris.

[bcantrill]

That is not correct. Hubris -- very importantly -- uses the MPU to isolate applications from one another and from the kernel: if any application accesses memory that it is not permitted to access (either in I/O space that has not been assigned to the application or in another application), it will fault and (by default) be restarted. Moreover, we make sure that the stack for a given application grows towards a protection boundary (rather than towards its own data), assuring that a stack overflow (our most common fault, by far!) does not result in an application corrupting its own data but rather in that application dying.

It is definitely true that Hubris does not have (and never will have) a dynamic loading facility: dynamic loading is very important to Tock, but we saw that it was taking us not just away from our use case but directly contrary to it. In contrast, Hubris has exclusively static task assignment -- which has proved to be a very important constraint for overall system robustness as it allows things task restart to happen without fear of unavailability of resources. Cliff Biffle expands on more details of Hubris in his OSFC 2021 talk[0].

I also don't think it's accurate to speak of an "exact use case" for Hubris, as we ourselves use it in disparate applications: among other things, it runs our root-of-trust, our service processor, our power shelf controller, and on our manufacturing line to program parts. What these use cases have in common is that they are embedded microcontrollers in which robustness is essential. This is not to say that Hubris is a fit for all embedded use cases, of course -- but the fit is certainly more broad than how we happen to be using it.

In terms of other contrasts to other embedded systems, we have spent quite a bit of time on debugging infrastructure, with our debugger being co-designed with the operating system; more details on this in Matt Keeter's OSFC 2023 talk.[1]

[0] https://talks.osfc.io/osfc2021/talk/JTWYEH/

[1] https://talks.osfc.io/open-source-firmware-conference-2023/t...

[comradelion]

Oops, sorry for the misrepresentation Bryan!

[bcantrill]

All good -- glad to see Tock getting some attention!

[fanf2]

Thanks, really informative!

[transpute]

> Microsoft's Pluton (rumor has it, for some future version anyway)

Which embedded OS does Pluton run today?

[comradelion]

Good question, I don't know! I would guess it's a home baked solution, but I believe Pluton, the hardware, is changing as well (I am not an authority on this, I only know a bit from talking with the developers at Microsoft who work on the next gen stuff).

[transpute]

Sounds promising. Pluton (AMD Ryzen and Qualcomm Snapdragon) running OSS Tock would be huge.