Re: [PATCH v2 net-next 5/9] psp: add unprivileged version of psp_device_get_locked

[Willem de Bruijn <willemdebruijn.kernel@gmail.com>]

> > >> From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
> > >> Sent: Wednesday, March 4, 2026 8:25 AM
> > >> To: Wei Wang; netdev@vger.kernel.org; kuba@kernel.org;
> > >> daniel.zahka@gmail.com; Willem de Bruijn; David Wei; Andrew Lunn;
> > >> David S. Miller; Eric Dumazet
> > >> Cc: Wei Wang
> > >> Subject: Re: [PATCH v2 net-next 5/9] psp: add unprivileged version of
> > >> psp_device_get_locked
> > >>
> > >>> Can you give a concise reason for which operations to allow from
> > >>> another netns and which to deny. Also as forward looking heuristic for
> > >>> when new operations may be added.
> > >>>
> > >>> Btw minor typo in first sentence of next commit: associcate.
> > >> Thanks for the comment!
> > >> Yes. "unprivileged" means access from the main netns as well as any
> > >> netns with an associated device and is used for commands like
> > >> dev-dump, dev-get, rx-assoc, tx-assoc, which are user-controlled
> > >> functionalities of the psd.
> > >> While "privileged" means access only from the main netns and is used
> > >> for dev-add/delete/change-ntf, key-rotate. This is more like the
> > >> admin-types of operations of the psd.
> > >> I will update the commit msg in the next version to make it more clear.
> > >
> > > I think Willem's question is more: what criteria did you use to decide
> > > if each operation is privileged or not? I think one reasonable answer
> > > would be: operations that have side effects on the psp dev's state,
> > > e.g. key rotations or changing the enabled psp versions.
> 
> Agree. And the current set of privileged operations should only include: dev-set, key-rotation.
> All others should be unprivileged I think...
> (The get-stats command which I should make sure they are called with unpriv = true. I will change that in the next version.)
> 
> >
> > well, now that I sent that I realize that criteria is so broad to
> > include things like rx-assoc and tx-assoc, which obviously need to be
> > unprivileged :(
> 
> Yes. tx-assoc and rx-assoc are currently implemented as unprivileged. They call psp_assoc_device_get_locked() which currently calls psp_dev_check_access() with unpriv = true.

Consider a more descriptive monitor than unprivileged too. As is, it's
not clear what privilege or capability is implied.

Perhaps just assoc_allowed?

(also please check your email: plain-text only)