Subject: Re: rpc xid randomness
To: None <email@example.com>
From: Thor Lancelot Simon <firstname.lastname@example.org>
Date: 09/06/2003 15:00:32
On Sat, Sep 06, 2003 at 01:56:12PM +0100, David Laight wrote:
> On Sat, Sep 06, 2003 at 09:23:29PM +0900, email@example.com wrote:
> > > does it have any negative sideeffects? i mean, is there any code that
> > > relies on xid being generated from timestamp?
> > clnt_vc.c: call_msg.rm_xid = ((u_int32_t)++disrupt) ^ __RPC_GETXID(&now);
> > how important "disrupt" is?
> Does it even matter if RPC xids are predictable?
> IIRC They are only used to tie responses to commands in the client.
> So what is really, really important is that there aren't two outstanding
> requests with the same xid - and I'm not even sure the code above does that!
I don't think it actually does matter. I also know that Larry McVoy
measured the overhead of randomizing RPC XIDs (and PIDs, and a number of
other things that OpenBSD randomizes) and concluded that it was quite large,
for the net benefit (which I believe he correctly characterized as small
or, in some cases, nonexistent).
I do not believe such changes should be committed to NetBSD without
extensive discussion. "Because OpenBSD does it" is not the same thing
as "this is necessary to avoid a security issue". There is definitely
some amount of cargo-cult "security" going on over there, along with all
the genuinely useful and innovative work.