netdev - Re: [PATCH 5/5] c/r: Add AF

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 04 Aug 2009 04:27:27 -0400
From:	Oren Laadan <orenl@...rato.com>
To:	Dan Smith <danms@...ibm.com>
CC:	containers@...ts.osdl.org, Alexey Dobriyan <adobriyan@...il.com>,
	netdev@...r.kernel.org
Subject: Re: [PATCH 5/5] c/r: Add AF_UNIX support (v6)



Dan Smith wrote:
> OL> Hmm.. then what happens when you have a circular dependency ?  For
> OL> example, three dgram sockets, A, B and C where: A->B, B->C and
> OL> C->A ('->' means connected).
> 
> So, I've been cooking up changes to the patch and a test for this
> case.  However, it seems like it's not valid, unless I'm missing
> something.  The man page for connect() says:
> 
>   If the socket sockfd is of type SOCK_DGRAM then serv_addr is the
>   address to which datagrams are sent by default, and the only address
>   from which datagrams are received.
> 
> So, even though you can connect() a DGRAM socket and then sendto()
> datagrams to a different location, it doesn't appear that the
> relationship between A and B is really valid, at least the connection
> between A and B is not functional.  In fact, in my testing, if you try
> to connect() C back to A, you get "Operation not permitted" because A
> is already connected elsewhere.

Weird ... I have a faint memory of seeing that happen (which is
why I brought it up).

Does this mean that a situation of A->B and B->C is valid only as
long as A->B is done first, otherwise A->B will fail because B will
already be connected to C ?

Then, the other problem is to restore correctly you need to mimic
the behavior of sendto() because of the way the skb references the
original socket for the write-buf accounting :(

In turn, this means that during checkpoint you need to record the
_origin_ of each buffer in the queue of afunix dgram sockets :((

Sigh :(((

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