On Thu, 11 Jul 2024 09:36:27 -0700 Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > 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. The security model is indeed external, but I'd like a Linux BMC config to allow turning off the protections but still using the same fundamental interfaces as we normally use for the safe stuff. I don't want 1) The CXL IOCTLs 2) FWCTL 3) Yet another interface. > > 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. Use case wise I agree this isn't the current primary in-band use case for fwctl, hence the rat hole introductory comment. > > 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. As long as I can enable it via a sensible interface (and don't need to spin another) that is fine by me. > > > 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. Two separate things here. For tunneling, there is plenty that will map to fwctl because it's just a transport question. The tunnel command itself has a CEL that says it might eat babies so we'd need to check the relevant CEL for the destination to make sure they were just as safe as non tunneled version. So it's just an implementation detail, be it a fiddly one. For destructive options sure it's a config problem. But I do want to be able to lock down the kernel on the BMC but still allow the discructive command. Lock down is protecting and restricting the BMC not the other hosts in this use case. > > > 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. Makes sense. Tunneled access to CXL features should be an a good explorative feature to do reasonably soon. Jonathan
