netdev - Re: [RFC PATCH 00/13] Ultra Ethernet driver introduction

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20250401193920.GD325917@nvidia.com>
Date: Tue, 1 Apr 2025 16:39:20 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Sean Hefty <shefty@...dia.com>
Cc: Bernard Metzler <BMT@...ich.ibm.com>,
	Roland Dreier <roland@...abrica.net>,
	Nikolay Aleksandrov <nikolay@...abrica.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"shrijeet@...abrica.net" <shrijeet@...abrica.net>,
	"alex.badea@...sight.com" <alex.badea@...sight.com>,
	"eric.davis@...adcom.com" <eric.davis@...adcom.com>,
	"rip.sohan@....com" <rip.sohan@....com>,
	"dsahern@...nel.org" <dsahern@...nel.org>,
	"winston.liu@...sight.com" <winston.liu@...sight.com>,
	"dan.mihailescu@...sight.com" <dan.mihailescu@...sight.com>,
	Kamal Heib <kheib@...hat.com>,
	"parth.v.parikh@...sight.com" <parth.v.parikh@...sight.com>,
	Dave Miller <davem@...hat.com>,
	"ian.ziemba@....com" <ian.ziemba@....com>,
	"andrew.tauferner@...nelisnetworks.com" <andrew.tauferner@...nelisnetworks.com>,
	"welch@....com" <welch@....com>,
	"rakhahari.bhunia@...sight.com" <rakhahari.bhunia@...sight.com>,
	"kingshuk.mandal@...sight.com" <kingshuk.mandal@...sight.com>,
	"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
	"kuba@...nel.org" <kuba@...nel.org>,
	Paolo Abeni <pabeni@...hat.com>
Subject: Re: [RFC PATCH 00/13] Ultra Ethernet driver introduction

On Tue, Apr 01, 2025 at 04:57:52PM +0000, Sean Hefty wrote:
> > > Specifically, I want to *allow* separating the different functions
> > > that a single PD provides into separate PDs.  The functions being page
> > > mapping (registration), local (lkey) access, and remote (rkey) access.
> > 
> > That seems like quite a stretch for the PD.. Especially from a verbs perspective
> > we do expect single PD and that is the entire security context.
> 
> From the viewpoint of a transport, the target QPN and incoming rkey
> must align on some backing security object (let's call that the PD).
> As a model, I view this as there needs to exist some {QPN, rkey, PD
> ID} tuple with appropriate memory access permissions.

Yes, but I'd say the IBTA modeling has the network headers select a PD
and then the PD limits what objects that packet can reach.

I still think that is a good starting point, and if there is more fine
grained limitations then I'd say each object has an additional ACL
list about what subset of the network headers (already within the PD)
that it can accept.

> The change here is to expand that tuple to include a job id: {QPN, rkey, job ID, PD ID}.

IB does QPN -> PD, if you do Job -> PD I think that would make
sense. If the QP is providing additional restriction that would be a
job for ACLs..

> I don't know that I can talk about the UEC spec, 

Right, it is too early to talk about UEC and Linux until people can
freely talk about what it actually needs.

> I can envision a job manager creating, sharing, and possibly
> controlling the PD-related resources.

Really? Beyond Job, what would make sense? Addressing Handles?

I wondering if addressing handles are really part of the job..

Jason