Back to Tock

Tock Meeting Notes 2025-04-09

doc/wg/core/notes/core-notes-2025-04-09.md

latest9.8 KB
Original Source

Tock Meeting Notes 2025-04-09

Attendees

  • Branden Ghena
  • Leon Schuermann
  • Johnathan Van Why
  • Brad Campbell
  • Benjamin Prevor
  • Hudson Ayers
  • Amit Levy
  • Pat Pannuto
  • Kat Fox
  • Viswajith Govinda Rajan

Updates

  • Brad: Tockloader 0.14 is released now. People should update and try that out
  • Amit: There is an x86 libtock-rs PR which should be userland for the x86 kernel PR. Very exciting
  • Amit: On Treadmill, Ben has multi-board BLE tests and most of the Thread tests that Tyler was running up and running on Treadmill. That'll be a PR soon
  • Benjamin: Confirmed
  • Amit: In working on a system for SOSP, Tyler got shortcuts working for the nRF 15.4 radio which makes it quite a bit faster, which is pretty cool. Anecdotally using those was a big blocker for robust BLE support. So good side progress on wireless networking front

Security Bug Report Process

  • Amit: We've recently gotten some security-related bug reports from Vivian at UCSD who has been doing verification stuff. So that raised the issue of having a process for handling bug reports, especially those with potential security vulnerabilities and those that could affect downstream. So we thought we should formalize and document a process for that
  • https://github.com/tock/tock/pull/4401
  • Amit: PR 4401 is a proposal for this process
  • Benjamin: In our discussions, we thought there would be two main ways to report a vulnerability. One of the tabs in the Tock repo is the security tab, which gives you a template for information to provide and discusses how to handle certain levels of critical-ness.
  • Benjamin: We also made a triage role for security vulnerability reporting, which I will be doing first. Then there will be contacts for various subsystem contacts who the issue will be farmed out to. I'll contact them saying that the issue exists and placing an initial estimate of severity.
  • Benjamin: If it is deemed to be a critical security issue, we'll publish a github security advisory for the repo and also send an email to a security mailing list. We'll also identify if there are any downstream users we're aware of who need to be notified early
  • Brad: How do we issue a "security advisory and CVE"?
  • Benjamin: Github has an option for this for a repo, I believe. For issuing a CVE, I'm not entirely sure. I'll look into that
  • Amit: We need to register as a partner with the CVE org
  • Leon: More anecdotally, the author of CURL has various grievances with the CVE process and has documented what to do and what not to do. They have some thoughts we should consider
  • Pat: We need two separate lists for notifying of bugs and announcing bugs publicly (general agreement)
  • Brad: What happens if you do not have a critical or sensitive vulnerability? Those instructions should be in this writeup too
  • Benjamin: I'll add that
  • Brad: And what makes something critical and sensitive versus not? Do we assume people will know?
  • Benjamin: If you're already not posting it as an issue you probably know it's a security vulnerability. But we should probably have some guidance and criteria
  • Brad: Why use the security tab at all? Is that more public which is why we'd use it?
  • Benjamin: The security tab goes to the repo maintainers
  • Leon: I had the same question. Historically, we haven't been good about hygiene about people who have the ability to contribute to the Tock repository. That's something we could more easily control with a dedicated security list
  • Brad: So maybe this is something to look into. This seems overly complicated. Why not just have one method for reporting?
  • Benjamin: That makes sense. It should probably be the security tab if possible since it's more central.
  • Brad: It's also fine to have the email for people who aren't sure
  • Branden: I might have the opposite opinion. We should use email instead. How does the Github tab work? Is that archived somewhere?
  • Benjamin: Good question. Email could be better
  • Amit: I'm also sympathetic to the issues of access control. Security vulnerabilities which haven't been patched and could affect deployed systems are probably more sensitive than adminstrative access to the github org
  • Brad: Not clear which one (email or github) is easier to control access on
  • Leon: One of the advantages of email for all its faults, is that everyone can send an email. Makes it more accessible
  • Hudson: It also allows us to have a single email for security reports for both tock and userlands and all the tools
  • Benjamin: We could add this SECURITY.md file which populates the Github Security tab for all our repos
  • Pat: Vivian actually expected the Github Security flow to exist and was surprised it didn't. Which is what prompted this work.
  • Amit: Okay. So broadly is there agreement with the high-level process? With the caveat that we'll direct people to one channel for reporting, likely email.
  • Branden: This PR was made like 15 minutes ago. So I'm not really sure. I agree with what was said here
  • Leon: So steps for merging this. One issue will be who the subsystem contacts are. How do we determine primary and secondary contacts for these?
  • Branden: There aren't that many people who are likely to be contacts for these. Just a few of us who work on Tock a ton
  • Amit: The volume will be low for now hopefully
  • Leon: It's important that they feel responsible to act on these

Explicit System Call Types

  • https://github.com/tock/tock/pull/4228
  • Pat: This has been on my todo queue, but personal life pulled me away from it for a few weeks now.
  • Pat: Nothing much else to discuss here. I have a path forward and I'll ping folks for review

Dynamic Process Loading

  • https://github.com/tock/tock/pull/3941
  • Brad: What's the bar for moving forward here?
  • Leon: I haven't gotten to address the new responses here
  • Amit: I haven't written comments, but my only significant concern is that there's a lot in the kernel crate which I'm pretty skeptical of whether it needs to be in the kernel crate. However, I don't really think that should block things. We can refactor later. So I should review this and avoid that problem
  • Brad: That's a perfectly reasonable question/comment. I think I disagree, but we could try to figure out. It's up to you how important you think it is
  • Amit: There's a bigger refactoring design question here. If I'm right that a lot of this could go outside the kernel, then great we should do that eventually. If I'm wrong, it's not as though we don't want to include this functionality. So despite wanting things to stay minimal in the kernel as much as possible. Upon reflection, I'm convincing myself that we want the functionality anyways so it's better to have it in the kernel for now than to not have it
  • Brad: I will add that I don't think there is anything other than the connection to the sequential process loader, which is in the kernel, that would tie this to the kernel crate in a way that would be hard to change in the future. It doesn't use internal APIs
  • Amit: That seems roughly right
  • Amit: So Leon and I can commit to giving this a look soon
  • Leon: I have spent quite a bit of time reasoning through this, but that's taking too much time. I'll focus on safety issues and as long as that looks good I'll approve
  • Hudson: For the TRD PR, there are open comments
  • Brad: We've been ignoring that PR for now, as the bar to merge that is even less clear than for this
  • Leon: The only persistent comment is the tight but non-explicit coupling between the app flash and app loader traits

CHERI RISC-V Support Assembly

  • Leon: I don't think we need to go into deep details. But we are getting to a fundamental question. We're increasingly seeing a problem where we're targeting different chips which share a ton of implementation with small minor internal details which are different. We used to have internal if statements based on constant values for the target, and we decided against that because of the difficulty of understanding what's included in the code. We also had the Cortex-M variants for adding small differences.
  • Leon: CHERI is pushing this further, adding internal switching based on the target in a way that's pretty invasive for RISC-V chips. This makes testing more challenging. So we need to decide if there's a clear line we can draw, or if we have to decide on a case-by-case basis
  • Amit: That's pretty general. Is there a more specific decision we're making?
  • Leon: A good example is if we have two chips and one needs an additional instruction in its trap handler. In many cases Tock has duplicated the code into two functions and picked which one to use.
  • Leon: This CHERI example does the opposite. It's one big assembly block with a bunch of compile-time choices for choosing which assembly to generate for different targets
  • Amit: Is the question "whether if configs should be used for similar assembly"? (yes)
  • Brad: And "should a macro be used to generate assembly on a per-target basis"?
  • Amit: There are some examples of this in the CHERI PR. https://github.com/tock/tock/pull/4365
  • https://github.com/tock/tock/blob/1f5fe2b968fd7163155c57b4f7698f9a1570e716/arch/riscv/src/syscall.rs specifically
  • Leon: I'll say I'm in awe of the engineering here. But it's quite challenging to read and understand
  • Brad: I see this as a question around: is Tock the minimal set of code needed to support the platforms and use cases we want, or not? For me, I don't see that the minimal set of code is a worthwhile goal. So as we get closer to hardware the variations are biggest and things are least dynamic because hardware is fixed. So code duplication makes sense there because things shouldn't change often.
  • Pat: I agree with you, but I'm mindful that we did mess up the Cortex-M0 context switch in a way that we had previously fixed in the Cortex-M4 version. And that lasted for years until Vivian found it
  • Amit: Okay, I think we'll have to carry on this discussion next time with more synthesized thoughts