netdev - Re: [PATCH v3 net-next 0/3] rds: IPv6 support

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

Date:   Wed, 18 Jul 2018 15:19:46 +0800
From:   Ka-Cheong Poon <ka-cheong.poon@...cle.com>
To:     Sowmini Varadhan <sowmini.varadhan@...cle.com>
Cc:     netdev@...r.kernel.org, santosh.shilimkar@...cle.com,
        davem@...emloft.net, rds-devel@....oracle.com
Subject: Re: [PATCH v3 net-next 0/3] rds: IPv6 support

On 07/17/2018 07:27 PM, Sowmini Varadhan wrote:
> On (07/17/18 13:32), Ka-Cheong Poon wrote:
>>
>> The app can use either structures to make the call.  When the
>> app fills in the structure, it knows what it is filling in,
>> either sockaddr_in or sockaddr_in6.  So it knows the right size
>> to use.  The app can also use IPv4 mapped address in a sockaddr_in6
>> without a problem.
> 
> tupical applications that I have seen in routing applicaitons
> will use a union like
>    union {
> 	struct sockaddr_in sin;
> 	struct sockaddr_in sin5;
>    }
> Or they will use sockadd_storage. Passing down the sizeoof that structure
> will do the worng thing thing in the existing code for ipv4 (even
> though it will not generate EFAOIT)..


What a typical socket (not routing) app will do is to pass in
the right sizeof based on the socket address structure in doing
things like connect() or bind().  The app needs to fill in the
structure correctly according to which one after all.  And this
avoids the unnecessary copy of garbage data from user to kernel.


>> Could you please explain the inconsistency?  An app can use IPv4
>> mapped address in a sockaddr_in6 to operate on an IPv4 connection,
>> in case you are thinking of this new addition in v3 of the patch.
> 
> bind() and connect() are using the sa_family/ss_family to have
> the application signal to the kernel about whether ipv4 or ipv6 is
> desired. (and bind and connect are doing the right thing for
> v4mapped, so that doesnt seem to be a problem there)
> 
> In this case you want the application to signal that info via
> the optlen.  (And the reason for this inconsistency is that you dont
> want to deal with the user->kernel copy in the same way?)


Because doing that can break existing RDS apps.  Existing code
does not check the address family in processing this socket
option.  It only cares about the address and port.  If the new
code suddenly checks that and use it to decide on the address
family, working app will break.  As I mentioned before, this
patch set does not change existing behavior.  And doing what
you mentioned will change existing behavior and break apps.


-- 
K. Poon
ka-cheong.poon@...cle.com