netdev - RFC: Use of "jiffies" vs "jiffies64" in the neighbour system.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 25 Mar 2015 11:11:45 +0100
From:	Ulf Samuelsson <ulf.samuelsson@...csson.com>
To:	<netdev@...r.kernel.org>
Subject: RFC: Use of "jiffies" vs "jiffies64" in the neighbour system.

If you run HZ = 1000, then jiffies will wrap around after 49,71 days.
This means that all time compares in the neighbour system will fail.

 From what I can see from "jiffies,h" there is no attempt to detect the 
wrap-around.

#define time_after(a,b)        \
     (typecheck(unsigned long, a) && \
      typecheck(unsigned long, b) && \
      ((long)(b) - (long)(a) < 0))
#define time_before(a,b)    time_after(b,a)

#define time_after_eq(a,b)    \
     (typecheck(unsigned long, a) && \
      typecheck(unsigned long, b) && \
      ((long)(a) - (long)(b) >= 0))
#define time_before_eq(a,b)    time_after_eq(b,a)

While the problem is not big for most users, I suspect it will
affect quality at the time of wrap-around.

It looks like garbage collection will stop in neigh_alloc,
since time has not passed time of last flush.

reachable time will no longer be recomputed in periodic_work

When you are in REACHABLE state, you will stay there,
since "now" will be before "confirmed" +"reachable_time",
so the entry will not be moved to DELAY or STALE,

If you are in delay state, you will move the entry
into REACHABLE even if you did not get a response.

and so on....

-- 
Best Regards,
Ulf Samuelsson

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html