I was hoping to discuss https://github.com/tock/tock/pull/4028. That PR enables two features for AppID: 1. Allows an AppID assignment policy to use the accepted credential when assigning IDs. This is important if the AppId is the public key used to verify a signature, for example. (This functionality used to exist and I removed it previously because of how process loading changed. Turns out we still need it.) 2. Helps developers use the accepted credential *correctly* when assigning an AppID. There are two issues/pitfalls that can arise when trying to use an accepted credential to assign an AppID. 1. The checker, while verifying the credential, has some state about the verification process that is necessary for assigning the AppID. Some examples: 1. The checker maintains a list of valid public keys that can verify signatures. The checker knows which public key was used to verify the signature. 2. The checker knows if the app was signed by the kernel developer or a third party (or both). 3. The checker has multiple public keys per organization, and knows which one signed the app. 2. TBF footers are *not* checked for integrity, and developers *must not* store any values in the footer that cannot be verified by the checker. Very little can be verified by the checker. If a public key is in the credential, the checker can validate that that public key matches the signature. But any other data cannot be verified and could be modified before the app is loaded on a board. To help with these issues, this PR also includes a `usize` that the checker can store with the accepted credential to provide information about the accepted credential that the AppID assignment policy can use. For issue #1: this would allow the process checker to keep track of some metadata about why it accepted the credential. For example it might store the index of the public key that verified the signature. Or it might store the upper 16 bits of the ShortId for the organization that signed the app. The value is opaque, and different policies/implementations can use it differently. The `Compress` trait (ie assigning ShortId) is *not* asynchronous. So from a software engineering viewpoint, whatever state the AppId assignment policy needs must be fetched in advance, and the policy can not re-run any verification steps. Therefore, the checker needs some way to communicate with the AppId assigner if the assigner is going to use any outcome of the verification process in its AppId assignment. For issue #2: this gives developers some way to attach state to an accepted credential without including that state in the credential itself. This isn't providing a correctness guarantee, but it is providing an alternative to what seems intuitively valid: just include it in the credential. Otherwise, developers that want to use different credentials to assign different AppIds can't (or have to build some sort of workaround). - Brad On Fri, Jun 21, 2024 at 11:12 AM Branden Ghena <branden@northwestern.edu> wrote:

The meeting today is cancelled as quite a few people are unavailable.

Most of us will be meeting in-person this coming week for TockWorld and we're excited to see you all there!

-Branden _______________________________________________ Devel mailing list -- devel@lists.tockos.org To unsubscribe send an email to devel-leave@lists.tockos.org