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

	search CERT or bugtraq (securityfocus.com) with keyword "predictable"
	or something like that.  you'll see fair amount of issues due to
	predictability of identifier.  therefore i think the benefit is not
	small/nonexistent.

	given horsepower of today's machine the computation overhead is
	smaller than the benefit we'll get. (well, some of you run pdp10,
	but don't you want your pdp10 be secure against id predictability
	attacks?)

itojun