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: <20240729145850.GD3371438@nvidia.com>
Date: Mon, 29 Jul 2024 11:58:50 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Jonathan Cameron <Jonathan.Cameron@...wei.com>
Cc: Borislav Petkov <bp@...en8.de>, 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, Mauro Carvalho Chehab <mchehab@...nel.org>
Subject: Re: [MAINTAINERS SUMMIT] Device Passthrough Considered Harmful?

On Mon, Jul 29, 2024 at 03:29:43PM +0100, Jonathan Cameron wrote:
> On Mon, 29 Jul 2024 15:38:39 +0200
> Borislav Petkov <bp@...en8.de> wrote:
> 
> > On Mon, Jul 29, 2024 at 01:45:12PM +0100, Jonathan Cameron wrote:
> > > One of the key bits of feedback we've had on that series is that it
> > > should be integrated with EDAC.  Part of the reason being need to get
> > > appropriate RAS expert review.  
> > 
> > If you mean me with that, my only question back then was: if you're going to
> > integrate it somewhere and instead of defining something completely new - you
> > can simply reuse what's there. That's why I suggested EDAC.
> 
> Ah fair enough. I'd taken stronger meaning from what you said than
> you intended. Thanks for the clarification.
> 
> > 
> > IOW, the question becomes, why should it be a completely new thing and not
> > part of EDAC?
> 
> So that particular feedback perhaps doesn't apply here.
> 
> I still have a concern with things ending up in fwctl that
> are later generalized and how that process can happen.

My intention with fwctl is that it should never technically inhibit
generalization. Someone should be able to come and implement a
concurrent kernel subsystem to operate the generalized thing. The
documentation attempts to explain this position.

I don't know anything about CXL here, but broadly you should very
thoughtfully put things into fwctl that are single-instance and become
"captured" by it, because this would impede a kernel mediated resource
sharing in future.

Like continuous memory scrubbing and EDAC is not really fwctl since it
is part of the main mission of a memory device. However evaluating the
memory to measure current ECC error rate for data collection and
debugging would be appropriate for fwctl.

If the HW can't share the units that are doing this ECC work then
ensuring fwctl is optional and secondary would be the best
option. Turn off in-kernel use of the scrubber unit then you can use
that unit for debugging. (as an example)

Jason