One of the purposes of the capability mechanism is to highlight to board/platform authors where "sensitive" things occur and to restrict access to them.

#4411 aimed to use ProcessManagementCapability in this way to highlight that including the ProcessInfo capsule on a board would, without filtering or some other protections, by default allow any userspace process to control any other process.

By creating the capability in the component, however, this ends up looking like "any other component" in a board. @alevy suggested that it probably makes sense to disallow capability creation in components generally, and to always require boards to pass references to components. That's a more invasive change, however, and merits a bit more discussion — hence this issue.

To help seed discussion, I'll add this:

Concrete Initial Proposal / Default Action: We should restrict the creation of capabilities exclusively to top-level board files*. We should document this policy and explain its rationale. We should refactor existing components to remove all capability creation, and lift them to board files.

*Open Question: Can we do this mechanistically (through visibility of creation) somehow?

Implement the policy of no capability creation in components.

• Remove grant capability creation from all components
• Resolve the need for the type to be passed to both the component constructor and the static creation macro
• Document this policy somewhere
• Forbid unsafe in components crate