netdev - Re: [MAINTAINERS SUMMIT] Device Passthrough Considered Harmful?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <66a81996d4154_2142c29464@dwillia2-mobl3.amr.corp.intel.com.notmuch>
Date: Mon, 29 Jul 2024 15:37:10 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Jason Gunthorpe <jgg@...dia.com>, Jonathan Cameron
	<Jonathan.Cameron@...wei.com>
CC: Dan Williams <dan.j.williams@...el.com>, <ksummit@...ts.linux.dev>,
	<linux-cxl@...r.kernel.org>, <linux-rdma@...r.kernel.org>,
	<netdev@...r.kernel.org>, <shiju.jose@...wei.com>, Borislav Petkov
	<bp@...en8.de>, Mauro Carvalho Chehab <mchehab@...nel.org>
Subject: Re: [MAINTAINERS SUMMIT] Device Passthrough Considered Harmful?

Jason Gunthorpe wrote:
[..]
> > We could say it can only be used for features we have 'opted' in +
> > vendor defined features, but I'm not sure that helps.  If a vendor
> > defines a feature for generation A, and does what we want them to by
> > proposing a spec addition they use in generation B, we would want a
> > path to single upstream interface for both generations.  So I don't
> > think restricting this to particular classes of command helps us.
> 
> My expectation for fwctl was that it would own things that are
> reasonably sharable by the kernel and userspace.
> 
> As an example, instead of a turning on a feature dynamically at run
> time, you'd want to instead tell the FW that on next reboot that
> feature will be forced on.
> 
> Another take would be things that are clearly contained to fwctl
> multi-instance features where fwctl gets its own private thing that
> cannot disturb the kernel.
> 
> I'm really not familiar with cxl to give any comment here - but
> dynamically control the single global scrubber unit seems like a poor
> fit to me.

Right, one of the mistakes from NVDIMM that was corrected for CXL was to
explicitly remove the passthrough capability for global state machine
controls like scrubbing.

Many of the "Immediate Configuration Change" CXL commands fall into this
bucket of things that may want to have a kernel-managed global view
rather than let userspace and the kernel get into fights about the
configuration. So, I think it is reasonable to say that scrub has a
kernel interface that goes through EDAC and not fwctl.

For the "anonymous" "Features" that advertise an "Immediate
Configuration Change" effect those need CAP_SYS_RAWIO at a minimum,
possibly a kernel taint, and/or compile time option to block them. Maybe
that encourages more "Configuration Change after Reset" Set Feature
capabilities which carry less risk of confusing a running kernel.