netdev - [PATCHv3 net-next 0/3] xfrm: Refactor xfrm

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]

Message-ID: <1376553043-19007-1-git-send-email-fan.du@windriver.com>
Date:	Thu, 15 Aug 2013 15:50:40 +0800
From:	Fan Du <fan.du@...driver.com>
To:	<tglx@...utronix.de>, <davem@...emloft.net>,
	<steffen.klassert@...unet.com>
CC:	<herbert@...dor.hengli.com.au>, <dborkman@...hat.com>,
	<netdev@...r.kernel.org>
Subject: [PATCHv3 net-next 0/3] xfrm: Refactor xfrm_state timer management 

The first version of "refactor xfrm_state timer management" has been
flushed into toilet since nobody but only me like it.

Anyway new approach here is updating SAs lifetime timeout whenever
clock_was_set is called, iow, system clock changed or host resume from
suspend state. Rule is simple, force soft expire for any SAs which has
not reach their soft expire limit and hard expire for those has experienced
soft expire timeout but wait for hard expire timeout to come.

Locking issue:
 - holding rtnl_lock when iterate on all net namespace.
 - holding xfrm_state_lock when iterate all xfrm_state in this net.
 - holding state->lock when changing xfrm_state.

Any comments would be wellcome! harsh or gentle :)

Thanks!

v3:
  - Fixing locking issue clock_change_callback reported by LOCKDEP.
  - Beautify notifier in clock_was_set as suggested by Daniel Borkmann.

v2: 
  - Instead of getting rid of original xfrm_state timer code almost completely,
    new approach is updating SA lifetime when clock_was_set is called.

v1:
  - The initiative of v1 is making xfrm_state timer independent of wall clock
    changing which could result in sudden SA termination or extremely long SA
    lifetime. So no need to read wall clock in timer handler and also
    unnecessary to turn on the timer for just 1 second as the original
    implementation. Simply start the timer right after SA is create for soft
    timeout, and after soft timeout happened, reload timer for hard timeout.


Fan Du (3):
  hrtimer: Add notifer when clock_was_set was called
  xfrm: Update xfrm_state lifetime expire after clock_was_set
  xfrm: Revert "Fix unexpected SA hard expiration after changing date"

 include/linux/hrtimer.h |    3 +++
 include/net/xfrm.h      |    4 ---
 kernel/hrtimer.c        |   19 ++++++++++++++
 net/xfrm/xfrm_state.c   |   65 ++++++++++++++++++++++++++++++++++-------------
 4 files changed, 70 insertions(+), 21 deletions(-)

-- 
1.7.9.5

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