Tock OT Notes 3/13/2020

Present:

• Brad Campbell (Chair), University of Virginia
• Jon Flatley, Google
• Garret Kelly, Google
• Alistair Francis, Western Digital
• Laura Abbott, Oxide Computer
• Patrick Mooney, Oxide Computer
• Bryan Cantrill, Oxide Computer
• Johnathan Van Why, Google
• Adam Leventhal, Oxide Computer

TODO

• Garret: Send out roadmap
• Brad: Send out calendar invite
• Brad: Send out pointer to Tock firmware update (included below)
• Garret: Open key,value store issue in tock/tock

Meetings

• Will meet Thursdays at:
  • 9 AM PT
  • Noon ET
  • 4 PM GMT

Updates

• Garret: have draft of roadmap
• Brad: core team working on Tock 1.5
• Add comments here https://github.com/tock/tock/issues/1685 if you have feedback on what should be in 1.5.
• Jon: Started Tock testing on host computer
• Running kernel on host with out-of-tree board
• Hardware resources will be running separately over unix sockets
• Current status: panics as things are unimplemented, but will continue to progress

Roadmap

• Garret: not quite a roadmap yet, but a prioritized list of goals mostly

• https://docs.google.com/document/d/1fAdIzo9WtbjVYClzFWy1ZAP7GEHjnSUaRyA24hZLTxc/edit#

• Update on size from Chromebook team:

  • Not a priority to reach 20-25 kB
  • Current size (~45 kB with patches) is already in a good spot
  • Since Tock includes features like memory safety and principled architecture, the size increase is worth it.

• Want to help with libtock-rs development and improvements

• Performance of syscalls

  • Competing OS has overhead of ~50 cycles
  • Implications for battery life, and we are considering two battery-based platforms.
  • Measurement needed to see where Tock stands currently

• key,value storage

  • Needed to keep state
  • Cannot store state inside of monolithic images because need redundancy and want to be able to update images.

• System updating

  • Want A/B slot system, ability to run a different monolithic image.

• Crypto

  • Need a crypto API that is usable for different scenarios
  • The Titan crypto API may be too app-specific

• Laura: re: size, any work on optimizing string literals? Are there patches in that area to help reduce size?

• Garret: No patches yet, but do want to remove most formatting machinery.

• Patrick: One idea is to remove unicode support. But that might require a change to TBF format.

• It would also have ramifications for what names an app could have.

• Brad: The key value store could be implemented in many different ways.

• Garret: It is further complicated by the flash architecture on OpenTitan.

• Brad: A higher-level k,v abstraction might be useful, and then there could be chip-specific implementations.

• Also, in-kernel logging was just merged into Tock. There may be some connection/interest to having a key value store.

• Might be good to open an issue around support for k,v support. I'm not aware of anyone working on it, but there might be larger interest.

• Garret: I will open an issue.

• Also, no need for community to implement, I expect someone at Google will implement this.

• Brad: We did at one point write a tool for updating the kernel on a Tock board.

  • Basic idea: an app would have access to a region of flash it could write. It would load a binary into that region, and then tell the kernel it had done so, including the address the binary is located at and where the binary should be moved to. The kernel would then save these addresses in the bootloader's flash, and reboot. The bootloader would then move the updated binary to the correct location. This allows this approach to update both the kernel an apps.
  • But, it is not robust (but was quick to implement).
  • Driver for an app to signal it saved a new binary: https://github.com/lab11/signpost-software/blob/master/signpost/kernel/signpost_drivers/src/signpost_tock_firmware_update.rs
  • Bootloader to do the copy: https://github.com/lab11/tock-bootloader/blob/master/src/main.c#L105

• Garret: Want something slightly different. Want to be able to load a new binary and switch to it.

• Brad: Agreed.

• Garret: Testing is not on the roadmap but should be. I have added it.

• Want on-host testing, perhaps using verilator for peripherals.

• Need coverage maps, and the ability for apps to pass coverage maps.

• Want to be able to test apps on the host as well.

• Want fuzz testing. More important for that to work on actual hardware, but would be nice to be able to run that on a host if possible.

• Adam: Want to be able to test applications independently

• Garret: Jon's work allows applications to run separately from the kernel and communicate over sockets.

• And applications would be tested against the actual kernel.

• Brad: What about DIFs and relocations?

• Garret: Relocations important long term

• Not as important short term

• Monolithic binary in the "B" slot good enough for now

• We can use fixed addresses.

• DIFs already in progress, but I will add to the roadmap

• Brad: Are relocations important for Oxide?

• Laura: Less of an issue in the short term.

• How is Google building fixed address apps?

• Garret: very manually by editing linker files in vim

• Laura: we need a more automated approach

• Not essential to have full relocations, but we need to be able to build multiple apps at fixed addresses and have them run.

• That also requires the kernel to give the correct RAM to processes when it loads them.

• Brad: Ok, so don't need NxK linking, but do need better tooling to make a known set of apps compile and load correctly?

• Laura: yes.

• Brad: I am interested in and can help with TBF extensions to enable apps to request specific memory locations.

• Laura: lowrisc might be helping with LLVM relocations. WD presented on their work on GCC, and that might get things moving. But probably a long lead time still.

• Brad: Core is working on Tock 2.0. Any syscall needs for opentitan?

• Garret: Worried about pre-emptable apps adding too much complexity

• Brad: Ok but it doesn't sound like there are any OT-specific updates that are needed.