Jonathan Cameron wrote: > On Tue, 9 Jul 2024 15:15:13 -0700 > Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > > > James Bottomley wrote: > > > > The upstream discussion has yielded the full spectrum of positions on > > > > device specific functionality, and it is a topic that needs cross- > > > > kernel consensus as hardware increasingly spans cross-subsystem > > > > concerns. Please consider it for a Maintainers Summit discussion. > > > > > > I'm with Greg on this ... can you point to some of the contrary > > > positions? > > > > This thread has that discussion: > > > > http://lore.kernel.org/0-v1-9912f1a11620+2a-fwctl_jgg@xxxxxxxxxx > > > > I do not want to speak for others on the saliency of their points, all I > > can say is that the contrary positions have so far not moved me to drop > > consideration of fwctl for CXL. > > I was resisting rat holing. Oh well... > > For a 'subset' of CXL. There are a wide range of controls that are highly > destructive, potentially to other hosts (simplest one is a command that > will surprise remove someone else's memory). For those I'm not sure > fwctl gets us anywhere - but we still need a solution (Subject to > config gates etc as typically this is BMCs not hosts). > Maybe fwctl eventually ends up with levels of 'safety' (beyond the > current read vs write vs write_full, or maybe those are enough). It is not clear to me that fwctl needs more levels of safety vs the local subsystem config options controlling what can and can not be sent over the channel. The CXL backend for fwctl adds the local "command effects" level of safety. For the "Linux as BMC" case the security model is external to the kernel, right? Which means it does not present a protocol that the kernel can reason about. Unless and until someone develops an authorization model for BMC nodes to join a network topology I think that use case is orthogonal to the primary in-band use case for fwctl. It is still useful there to avoid defining yet another transport, but a node that has unfettered access to wreak havoc on the network is not the kernel's problem. > Complexities such as message tunneling to multiple components are also > going to be fun, but we want the non destructive bits of those to work > as part of the safe set, so we can get telemetry from downstream devices. > > Good to cover the debug and telemetry usecase, but it still leaves us with > gaping holes were we need to solve the permissions problem, perhaps that > is layered on top of fwctl, perhaps something else is needed. But that's more a CXL switch-management command security protocol problem than fwctl, right? In other words, as far as I understand, there is no spec provided permission model for switch management that Linux could enforce, so it's more in the category of build a kernel that can pass any payload and hope someone else has solved the problem of limiting what damage that node can inflict. > So if fwctl is adopted, I do want the means to use it for the highly > destructive stuff as well! Maybe that's a future discussion. > > > Where CXL has a Command Effects Log that is a reasonable protocol for > > making decisions about opaque command codes, and that CXL already has a > > few years of experience with the commands that *do* need a Linux-command > > wrapper. > > Worth asking if this will incorporate unknown but not vendor defined > commands. There is a long tail of stuff in the spec we haven't caught up > with yet. Or you thinking keep this for the strictly vendor defined stuff? Long term, yes, it should be able to expand to any command code family. Short term, to get started, the CXL "Feature" facility at least conveys whether opcodes are reads or writes, independent of their side effects, and are scoped to be "settings". There is still the matter of background commands need to support cancellation to avoid indefinite background-command-slot monopolization, and there are still commands that need kernel coordination. So, I see fwctl command support arriving in stages.
