Greg KH wrote: > On Mon, Jul 08, 2024 at 03:26:43PM -0700, Dan Williams wrote: > > Enter the fwctl proposal [1]. From the CXL subsystem perspective it > > looks like a long-term solution to the problem of managing expectations > > between hardware vendors and mainline subsystems. It disclaims support > > for the fast-path (data-plane) and is targeted at the long tail of > > slow-path (config/debug plane) device-specific operations that are often > > uninteresting to mainline. > > That's not true at all, device-specific operations are very interesting > to mainline, and I would argue that the "slow-path" is the most > important thing for the kernel to manage as that is where the security > and unification layers can be properly enforced. > > Vendors that think the control plane should just be allowed to be > accessed by userspace "blindly" are not saying outloud that they just > want to circumvent the security layer entirely like they previously were > doing by directly accessing /dev/mem which is one of the strongest > reasons to keep enforcing this through the kernel as Christoph points > out. > > It's the cumulation of multiple vendors of semi-alike config paths that > allow us to standardize them to provide the most important thing of all, > a unified view to userspace where a user does not care about what type > of hardware is running, which is really the goal of Linux as well, but > directly goes against what a vendor wants to have happen. 100% agree and this is the argument I made for creating tsm-report-configfs. What I meant by "config-plane" is something more along the lines of an FPGA bitstream redefining device parameters that get realized after a reset, less the in-band live-config-plane of a device that is likely similar across a class of devices where the kernel has a clear interest in mediating. A fuzzier example is that CXL has commands like "read vendor debug log" and I can see a device having specific control toggles to modify the data the device dumps into that log. The expectation is the device designer will put anything of general/kernel interest into other formal telemetry commands. That "vendor debug log" command is trusted to not have other kernel relevant side effects, it just facilitates debug between end users and device manufacturers. > > It sets expectations that the device must > > advertise the effect of all commands so that the kernel can deploy > > reasonable Kernel Lockdown policy, or otherwise require CAP_SYS_RAWIO > > for commands that may affect user-data. > > Yes, this is a good start, but it might still be too "vendor-specific" > at this point in time. This gets back to the trusted protocols point that Christoph raised. The community has examples where this tension is resolved with negotiated protocol concessions. The fwctl discussion has not progressed to the protocol concessions phase. > > It sets common expectations for > > device designers, distribution maintainers, and kernel developers. It is > > complimentary to the Linux-command path for operations that need deeper > > kernel coordination. > > Yes, it's a good start, BUT by circumventing the network control plane, > the network driver maintainers rightfully are worried about this as > their review comments seem to be ignored here. The rest of us > maintainers can't ignore that objection, sorry. Hence a mediated discussion proposal because the on list debate has a visible deficit of trust that email is unlikely to overcome.
