| > The key point where the new definition differs from the old is that _the
relation_
| > before(x,y) is unambiguous: the case "before(x,y) && before(y,x)" will no
longer occur.
|
| This is highly dependent on how the before macro is used in actual code.
| There is nothing to suggest that this change won't create new security
| holes in DCCP or any other protocol that uses this macro. The only
| way to be sure is to audit every single use.
I fully agree, merely changing the definition means going only half way.
| So I think we need to do one of two things:
|
| 1) Audit every single before/after check to ensure that it works
| correctly with the new definition.
For DCCP I will perform such an audit and post the results to [EMAIL PROTECTED]
With regard to TCP: I am heavily snowed under with other work at the moment. If
there
are experienced TCP people on the list who would be happy to look at this, it
would be
great. I counted the number of times before() is used - it amounted to 68.
There are
of course obvious cases which are quick to dismiss, but in particular the
example you
presented yesterday points out that careful analysis is needed.
I asked Dave to revert to the old TCP definition (patch has been committed);
for the moment
this seems the safest thing to do.
| 2) Change before/after such that before(x, x+2^31) == !before(x+2^31, x).
This is what the new definition does: in the old definition we always have that
before(x, x+2^31) == before(x+2^31, x).
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
