I had a chance over the past couple weeks to speak with Lawrence Esswood on the Pixel team at Google and with Tony Chen & Nasmus Sakib on the Pluton team at Microsoft about their use of Tock. I'm planning to follow up with both after the holidays. With Lawrence there is some specific follow ups related to memory tagging, but also to keep the conversation going. With Tony & Nasmus, we'll set up additional conversations with some of the developers who have some feedback and thoughts, particuarly on libtock-c. # Some high-level common points 1. Both groups have been using Tock for a while (at least a year in both cases) and both did a fairly broad survey to decide what to use. 2. Both are not yet shipping products, but both are on the path to shipping Tock in their products 3. Both are basically targeting secure elements within a larger SoC 4. Both are working with tagged memory, which is cool. # Lawrence @ Pixel Background: Lawrence was a PhD student of Robert Watson's at Cambridge working on CHERI. He's been at Google for a bit more than a year working on the (future) secure element for Pixel. * They have a separate fork of Tock than Ti50. Two promising and noteworthy differences: * They have already done a rebase to upgrade to Tock 2.0, meaning they've already experienced the downside of forking and seemed to have weathered OK. * They have particular and very interesting things in the plan to contribute upstream now that they have more cycles (basically the team is growing). One is support for 64-bit platforms, another is zero-copy I/O. Lawrence already had a very good handle on the trade-off involved and was very prepared to both defend the choices, how to limit impact on non-users, and also prepared to be convinced of different designs or that it may not make sense upstream (I was convinced that in some form both of these make sese) * Their use case is very similar to what we envisioned Tock being particularly good for. * They are/will be a team of people working on the kernel and a _separate_ team of "developers" building applications. All from Google, but nonetheless different * Code size is a non-issue for them. Everything is in SRAM, but they have between 1MB-10MB of SRAM and it's just not something they've run into at all so far. # Pluton * Pluton is basically a general hardware component they are expecting to have on all Windows PCs/laptops/whatever baked into the SoC from a variety of vendors starting pretty soon * So this is another microcontroller-on-die-with-a-CPU * They chose and are basically sticking with Tock * Tony Chen (the main guy: https://www.microsoft.com/en-us/research/people/tonychen/) said he wasn't sure if there is hardware shipping yet, but said there will be at some point, presumably in the not so far future, but idk * For them, future applications will be written in Rust, but they have a bunch of existing applications that are in C * They are using libtock-c and they have feedback/suggestions/requests (one of the people in the meeting was IMing with some of the devlopers who told confirmed, so we'll maybe here more) * Pluton doesn't necessarily have CHERI, but likely will have capabilities hardware (it's going to be a vendor-specific choice). They are probably going to replace MPU/PMP with capabilities where they can. * Evolution was very much: we had a home-baked non-OS from the xbox days, it slowly evolved to be more and more complex, we surveyed for what kind of more "real" OS made sense, and Tock makes the most sense.