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: <2024070910-rumbling-unrigged-97ba@gregkh>
Date: Tue, 9 Jul 2024 12:01:06 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Dan Williams <dan.j.williams@...el.com>
Cc: ksummit@...ts.linux.dev, linux-cxl@...r.kernel.org,
	linux-rdma@...r.kernel.org, netdev@...r.kernel.org, jgg@...dia.com
Subject: Re: [MAINTAINERS SUMMIT] Device Passthrough Considered Harmful?

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.

> 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.

> 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.

> 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.

SHould be a fun discussion, thanks for proposing this.

greg k-h