On Sat, Sep 06, 2003 at 01:56:12PM +0100, David Laight wrote:
> On Sat, Sep 06, 2003 at 09:23:29PM +0900, itojun@iijlab.net 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.

Thor