On Wed, 2024-08-28 at 09:41 +1000, NeilBrown wrote: > On Wed, 28 Aug 2024, Trond Myklebust wrote: > > On Wed, 2024-08-28 at 07:49 +1000, NeilBrown wrote: > > > On Tue, 27 Aug 2024, Trond Myklebust wrote: > > > > > > > > > > > > > > > > On Aug 25, 2024, at 9:56 PM, NeilBrown <neilb@xxxxxxx> > > > > > > wrote: > > > > > > > > > > > > While I'm not advocating for an over-the-wire request to > > > > > > map a > > > > > > filehandle to a struct nfsd_file*, I don't think you can > > > > > > convincingly > > > > > > argue against it without concrete performance measurements. > > > > > > > > > > > > > What is the value of doing an open over the wire? What are you > > > > trying > > > > to accomplish that can't be accomplished without going over the > > > > wire? > > > > > > The advantage of going over the wire is avoiding code > > > duplication. > > > The cost is latency. Obviously the goal of LOCALIO is to find > > > those > > > points where the latency saving justifies the code duplication. > > > > > > When opening with AUTH_UNIX the code duplication to determine the > > > correct credential is small and easy to review. If we ever > > > wanted to > > > support KRB5 or TLS I would be a lot less comfortable about > > > reviewing > > > the code duplication. > > > > > > So I think it is worth considering whether an over-the-wire open > > > is > > > really all that costly. As I noted we already have an over-the- > > > wire > > > request at open time. We could conceivably send the LOCALIO-OPEN > > > request at the same time so as not to add latency. We could > > > receive > > > the > > > reply through the in-kernel backchannel so there is no RPC reply. > > > > > > That might all be too complex and might not be justified. My > > > point > > > is > > > that I think the trade-offs are subtle and I think the FAQ answer > > > cuts > > > off an avenue that hasn't really been explored. > > > > > > > So, your argument is that if there was a hypothetical situation > > where > > we wanted to add krb5 or TLS support, then we'd have more code to > > review? > > > > The counter-argument would be that we've already established the > > right > > of the client to do I/O to the file. This will already have been > > done > > by an over-the-wire call to OPEN (NFSv4), ACCESS (NFSv3/NFSv4) or > > CREATE (NFSv3). Those calls will have used krb5 and/or TLS to > > authenticate the user. All that remains to be done is perform the > > I/O > > that was authorised by those calls. > > The other thing that remains is to get the correct 'struct cred *' to > store in ->f_cred (or to use for lookup in the nfsd filecache). This was why the original code called up into the sunrpc server domain code, and hence did consult with mountd when needed. Is there any reason to believe that we shouldn't be able to do the same with future security models? As I said, the client has direct access to all the RPCSEC_GSS/TLS session info, or other info that might be needed to look up the corresponding information in knfsd. In the worst case, we could fall back to sending on-the-wire info until the relevant context information has been re-established. > > > > > Furthermore, we'd already have established that the client and the > > knfsd instance are running in the same kernel space on the same > > hardware (whether real or virtualised). There is no chance for a > > bad > > actor to compromise the one without also compromising the other. > > However, let's assume that somehow is possible: How does throwing > > in an > > on-the-wire protocol that is initiated by the one and interpreted > > by > > the other going to help, given that both have access to the exact > > same > > RPCSEC_GSS/TLS session and shared secret information via shared > > kernel > > memory? > > > > So again, what problem are you trying to fix? > > Conversely: what exactly is this FAQ entry trying to argue against? > > My current immediate goal is for the FAQ to be useful. It mostly is, > but this one question/answer isn't clear to me. The question arose from the feedback when Mike submitted the earlier drafts in the beginning of July. I was on vacation at the time, but my understanding is that several people (including some listed in the MAINTAINERS file) were asking questiona about how the code would support RPCSEC_GSS and TLS. The FAQ entry is a direct response to those questions. I'm happy to ask Mike to drop that entry if everyone agrees that it is redundant, but the point is that at the time, there was a set of questions around this, and they were clearly blocking the ability to submit the code for merging. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
