netdev - Re: [RFC PATCH 0/6] udp: add encapsulation socket destroy hook

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-prev] [day] [month] [year] [list]

Date:	Fri, 15 Feb 2013 16:02:36 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	tparkin@...alix.com
Cc:	netdev@...r.kernel.org, jchapman@...alix.com, celston@...alix.com
Subject: Re: [RFC PATCH 0/6] udp: add encapsulation socket destroy hook

From: Tom Parkin <tparkin@...alix.com>
Date: Fri, 15 Feb 2013 10:25:13 +0000

> While working on an issue in l2tp relating to tunnel cleanup I discovered a
> problem which I think may require a new hook in udp core to resolve.  The l2tp
> code uses encapsulated udp sockets, and it needs to know when a socket is
> being closed in order to clean up.  Since sessions hold a reference to the
> tunnel socket, hooking sk_destruct isn't sufficient: any tunnel with sessions
> running in it will be pinned open by the sessions.
> 
> To resolve this, the first patch in this series adds a .destroy hook to udp, 
> while the following patches show how I'd use this feature in l2tp.  Essentially 
> the .destroy callback is used to close the sessions in the tunnel, thereby 
> dropping the socket references.
> 
> Does this seem like a reasonable approach?  I'm reluctant to modify udp, but
> I've not managed to discover a safe alternative...

For now this is fine by me.

If we commonly start to encapsulate in other datagram protocols we'll
need to facilitate this more generically, perhaps by having something
that hooks in near the sk_prot->destroy() in sk_release_common().
--
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