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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID:
 <DM6PR12MB43131BED0E6CD4B490903133BDAE2@DM6PR12MB4313.namprd12.prod.outlook.com>
Date: Thu, 3 Apr 2025 01:30:40 +0000
From: Sean Hefty <shefty@...dia.com>
To: Jason Gunthorpe <jgg@...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.

My claim is PD selection is made using the QPN and rkey.

For the model, QPN -> PD and rkey -> PD are deterministic, and both must select the same PD.  The SW model reflects this.  I think UEC can fit this model.

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

I'm unclear on the contents of the ACL, but I'm also unsure it's needed.

> > 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 believe job id -> PD works.  To enable job-secure MRs, I believe rkey -> job ID is needed and not properly captured by an ACL or QP setting.  Rkey -> job ID is optional, but deterministic.

To keep the model simple, all QPs under the same PD would belong to the same set of jobs.  If this makes sense to you, I can discuss in the UEC to see if all the above work.

To summarize, the SW object model looks like:

create_pd(&pd)
create_qp(pd, &qp)
create_job(pd, &job)
reg_mr(pd, [job], access, &mr)
share_mr(mr, [job], access, &new_mr) -- get a new rkey

I include share_mr() for completeness, but I don't think it needs to be an explicit part of a common uABI.

A gap in this model relative to libfabric is supporting NICs which associate MRs directly with QPs.  Similar to share_mr(), I believe it can be handled directly by the NIC vendor and should not impact a common uABI.

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

My thoughts were allocating and configuring the QPs.  Given the above model, this could include the job setup.  (I can also envision a process not having the ability to create or modify QPs or jobs).

Addressing is probably a separate discussion, which I'm happy to defer defining for later.  IMO, it makes sense to share addressing among processes to reduce the memory footprint.  This is best handled by the job manager populating some address table.  UEC has also publicly mentioned 'group keying' for security, which suggests attributes applied to a collection of addresses related by job.  So, I think there will be uABI concerns here.

- Sean