Tock OT Notes 3/19/2020

Present:

• Brad Campbell (Chair), University of Virginia
• Jon Flatley, Google
• Garret Kelly, Google
• Phil Levis, Stanford
• Silvestrs Timofejevs, lowRISC
• 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

• @gkelly: open PR for OT roadmap

Updates

• Silvestrs: Looking into conditional compilation where the same Tock board can be compiled for slightly different hardware platforms, like FPGA vs. verilator.
• Also going to be starting on integrating DIFs to implement Tock drivers.
• Garret: Updated syscall filter PR, looking for review.
• Opened Key-Value store issue, open for any discussion
• Phil: working on timer redesign
• https://github.com/tock/tock/tree/time-redesign-v3
• Includes discussion from @pfmooney and @gendx
• Also writing TRD which explains why it is designed as it is
• Might be worth discussing next week if there are still large open issues
• Laura: Great to see work on tracking size in tock/tock PRs

Roadmap

• Brad: Any comments on the roadmap?
• JVW: Why is testing P0, before even the change to libtock-rs?
• Garret: To make clear that testing is a priority. We want to test continuously as different items are developed.
• JVW: Ok, so the roadmap items are more levels of importance, not an ordering.
• Garret: Yes.
• Phil: Suggestion: for the other tasks to be complete there must be testing included. So its more of an on-going task that spans the other goals.
• Garret: Agreed.
• Garret: Everyone should have comment access if you want to make comments on the doc itself.
• Phil: Running tests on host seems like a large item. What is the scope of that? What does it mean for it to run on host?
• Garret: Verilator is fine but slow. On host we envision apps running in a unix process, with the kernel running in another unix process. Would support normal Tock functions like IPC. Much easier to implement testing and fuzzing with host-side tools.
• Difficult to do some of that testing and fuzzing on device or with verilator.
• Brad: Jon, any idea on the scope?
• Jon: Only preliminary support so far, so not sure what the scope will end up being.
• Phil: I suggest breaking up the items into more fine-grained milestones. Help with scope and allow for wins as progress is made.
• Garret: Agreed.
• Phil: Key-value vs. filesystem, those aren't quite the same?
• Garret: I mean key-value, filesystem is a borrowed term from Chromebook team. I will change it.
• Brad: What about the kernel implementation and support?
• Garret: That is necessary for all of this, and as such implicit.
• Makes sense to add it, however.
• Difficult to make too detailed, not clear what all the peripherals are yet.
• Brad: We can update with details over time. Adding it makes it more clear and another thing to check off to show progress.
• Brad: Where should we put the roadmap?
• Garret: I was thinking posting it as an issue.
• Laura: Issues feel rather short term, it might be better as a file in the repo.
• Garret: That makes sense.
• Adam: Github also supports projects, which would map well to this.
• Brad: Projects would make sense, but we haven't been able to get them to stick as a Tool for Tock development.
• Garret: Interesting, I'm looking at projects now.
• Brad: I agree with the file, and issues can be for sub-items.
• Garret: Makes sense, I will open a PR.

HMAC

• Alistair: Does userspace need HMAC access?
• Garret: I believe so. JVW implementation for Titan had it, but that is probably not the final API. Probably want a broader userspace API that might end up using multiple hardware blocks.
• Alistair: Will both userspace and the kernel need access to the HMAC HW? Will we need to support multiple keys?
• Garret: Yes, will need multiple users and multiple keys. Keys will have to be stored somewhere. Cannot leave the key in the HMAC HW peripheral.
• Alistair: Does AES have a userspace API?
• Brad: No, I don't think so. RNG does, but I don't remember ever seeing an AES app.
• The virtual_ capsule approach is probably what you want. That provides an interface for multiple in-kernel users, and one of those can be a userspace capsule.