Capability propagation controls
3 views
Skip to first unread message
Justin Mattson
Jun 11, 2021, 4:52:50 PM6/11/21
to component-framework-dev
Recent discussion on the system critical components RFC made me wonder if it would be useful for capability routing declarations to have controls around how they're propagated. For example, we could imagine a parent offering a capability to a child, but saying that the capability can not be routed farther. If Child tried to offer the capability to GrandChild, the routing would fail. Also you might say the capability can't be duplicated, so if Parent offered a singleton capability to Child, then Child could offer it to GrandChildA, but not also to GrandChildB.
This all immediately makes me think of Zircon handle rights for transferring and cloning. Not sure if that has any implications.
Cheers,
Justin
Aaron Wood
Jun 11, 2021, 6:19:45 PM6/11/21
to Justin Mattson, component-framework-dev
This is interesting, because I've been thinking along the same lines, but in the inverse direction, while working on the design draft for sub-assemblies: Can/should sub-assemblies, and their defined fragments of topology, constrain the bounds of routing?
The use-cases I'm thinking about is making sure that fidl protocols between siblings are constrained in known patterns (primarily by adding some extra non-executable components to the topology that serve as routing barriers.
The use-cases I'm thinking about is making sure that fidl protocols between siblings are constrained in known patterns (primarily by adding some extra non-executable components to the topology that serve as routing barriers.
E.g. '/root/core/swd', which then can route capabilities between the components of the swd stack, while knowing that they won't be exposed to any other children of 'core'.
Obviously (I hope), this is doable today, with the existing framework we have. But it's something that I don't see us doing.
--
All posts must follow the Fuchsia Code of Conduct https://fuchsia.dev/fuchsia-src/CODE_OF_CONDUCT or may be removed.
---
You received this message because you are subscribed to the Google Groups "component-framework-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to component-framewo...@fuchsia.dev.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CA%2BX8dX_nNRjVBWKLXhexiaZs%2BxH2aPDdcsquWSE6VgbDWf1%2Bqw%40mail.gmail.com.
Aaron Wood
Jun 11, 2021, 7:08:57 PM6/11/21
to Bryan Henry, Justin Mattson, component-framework-dev
Applying that model (allowed_monikers) to children seems workable, but I don't think it can be used beyond a single child (and not at all on the parent), as that requires knowledge that the component doesn't have at compilation time: the monikers of its parent(s) or grandchildren.
On Fri, Jun 11, 2021 at 4:02 PM Bryan Henry <bryan...@google.com> wrote:
Aaron: We do already have the ability to define policy for which monikers (and, a very recent addition, which realms or collections) specific capabilities are allowed to be used by. See http://cs/fuchsia/sdk/fidl/fuchsia.component.internal/config.fidl?l=185That's a little bit different than coarser grained "nothing in /root/core/swd can be exposed out of /root/core/swd, except these things", but IMO that's type of thing is better handled through the subassembly interface design (if we go that route).
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CAAi0OqavCi3_3wpNNEjk6h-%2BFR9QTwq_TwOs7H%3Dkg-HGvd9ejQ%40mail.gmail.com.
Bryan Henry
Jun 11, 2021, 7:22:24 PM6/11/21
to Aaron Wood, Justin Mattson, component-framework-dev
The capability policy we've put in place so far is focused on the allowed users of a specific capability, without constraining the intermediate routing. IMO that has felt like the right balance; we don't really care about constraining the intermediate routing, just the usages.
What use case do you have in mind for wanting to constrain the routing in addition to that?
On Fri, Jun 11, 2021 at 3:19 PM 'Aaron Wood' via component-framework-dev <component-f...@fuchsia.dev> wrote:
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CAAi0OqavCi3_3wpNNEjk6h-%2BFR9QTwq_TwOs7H%3Dkg-HGvd9ejQ%40mail.gmail.com.
Bryan Henry
Jun 11, 2021, 7:22:24 PM6/11/21
to Aaron Wood, Justin Mattson, component-framework-dev
Where I was going with that is this: I could imagine us expanding our existing capability policy infrastructure to support components also declaring such policy at the point where the capability is declared. For example, this would constrain users to the listed relative monikers, and be combined with the global policy that's loaded from CM's config:
capabilities: [
{
protocol: "fuchsia.foo.Bar",
allowed_monikers: [ "./baz" ]
},
{
protocol: "fuchsia.foo.Bar",
allowed_monikers: [ "./baz" ]
},
]
That gets less useful for longer relative monikers, but it does help with the example you gave about allowing a child but not grandchild. Still, I'm curious about the use case. In general I'd say we don't want to be putting such restrictions in place without very good reason. Children components should generally be able to decide how to structure themselves and perform whatever role they're meant to perform without the parent caring about whether it has further children or not.
Bryan Henry
Jun 11, 2021, 7:56:45 PM6/11/21
to Aaron Wood, Justin Mattson, component-framework-dev
Correct, but it's hard to say what would actually be needed here without a use case in mind. Without any other context I'd answer the direct question with "no, it seems overly restrictive to try and constrain things in this way". If foo.cml is performing some role that involves it consuming [A,B,C] and providing [D,E,F] capabilities, why should the parent care if foo.cml splits its responsibilities between one or more children?
Bryan Henry
Jun 14, 2021, 4:47:53 AM6/14/21
to Aaron Wood, Justin Mattson, component-framework-dev
Aaron: We do already have the ability to define policy for which monikers (and, a very recent addition, which realms or collections) specific capabilities are allowed to be used by. See http://cs/fuchsia/sdk/fidl/fuchsia.component.internal/config.fidl?l=185
That's a little bit different than coarser grained "nothing in /root/core/swd can be exposed out of /root/core/swd, except these things", but IMO that's type of thing is better handled through the subassembly interface design (if we go that route).
On Fri, Jun 11, 2021 at 3:19 PM 'Aaron Wood' via component-framework-dev <component-f...@fuchsia.dev> wrote:
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CAAi0OqavCi3_3wpNNEjk6h-%2BFR9QTwq_TwOs7H%3Dkg-HGvd9ejQ%40mail.gmail.com.
Justin Mattson
Jun 15, 2021, 1:44:00 PM6/15/21
to Bryan Henry, Aaron Wood, component-framework-dev
I was approaching this thinking from the other direction, which is to say asking "If we had this, what happens? Anything useful?" Since the answer I had to these questions was "hmmm, I don't know" I thought I'd share this thinking and see if it clicks with anyone else.
I often observe when I think in this direction I receive a challenge back of coming up with a use case. I will attempt to be more clear in the future when sharing ideas if I'm not trying to solve a problem known to me, but rather wondering if an idea might lead to a solution to a problem unknown to me.
Cheers,
Justin
Bryan Henry
Jun 15, 2021, 2:07:33 PM6/15/21
to Justin Mattson, Aaron Wood, component-framework-dev
It's really less a challenge and more a "I don't know what problem you're trying to solve so I don't know if what I'm saying is helpful or violates your requirements in other ways". Design in a vacuum is fraught with peril. Yeah if you're just spitballing an idea then it'd be helpful to know that, sure.
Reply all
Reply to author
Forward
0 new messages