netdev - Re: [PATCH 0/4] RFC: raw IPv6 address parsing in NFS client

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:	Mon, 19 May 2008 13:55:27 -0400
From:	Chuck Lever <chuck.lever@...cle.com>
To:	netdev@...r.kernel.org
Cc:	Jeff Garzik <jeff@...zik.org>
Subject: Re: [PATCH 0/4] RFC: raw IPv6 address parsing in NFS client

On May 18, 2008, at 10:13 PM, Jeff Garzik wrote:
> Chuck Lever wrote:
>> Hi-
>> I'm interested in some review of the following four patches which  
>> add to
>> the kernel's NFS client the ability to parse IPv6 addresses in  
>> presentation
>> format.
>> Namely, it adds the following:
>> 1.  If the user passes in an IPv6 address as the server name, the  
>> colons
>>    in the address will confuse the logic that splits the device name
>>    into a server hostname and an export path.   We'll use square  
>> brackets
>>    around IPv6 server addresses to "escape" the colons, as does  
>> Solaris.
>> 2.  If the user passes in a link-local IPv6 address as the server  
>> name,
>>    an interface index is also necessary.  We'll use the "%id"  
>> suffix on
>>    the address to pass in the index, and plant that in the sockaddr's
>>    sin6_scope_id field.
>> In addition to the following patches in email, a git repo with these
>> same patches already applied can be found here:
>> 	linux-nfs.org:exports/cel-2.6.git
>> The basic questions:
>> Are these reasonable conventions to follow?  Is the parsing logic  
>> adequate?
>> Is there anything I'm forgetting?
>
> I would take a look at the underlying components of glibc's  
> getnameinfo(), which must parse IPv6 addresses according to POSIX  
> specifications, IIRC.
>
> Comments:
>
> 1) bracket escaping seems reasonably common.  browsers and other  
> apps sometimes use that convention too.
>
> 2) an interface name rather than index should be used

A few follow-up questions (for anyone, not just Jeff):

Should the kernel ignore any incoming scope/interface identifier  
unless it verifies the address is link-local?

Do we really have to worry about the character set of incoming C  
strings?

        NI_IDN If  this  flag is used, then the name found in the
               lookup process is converted from IDN format to the
               locale’s encoding  if  necessary.  ASCII-only names
               are not affected by the conversion, which makes this
               flag usable in existing programs and environments.

        NI_IDN_ALLOW_UNASSIGNED, NI_IDN_USE_STD3_ASCII_RULES
               Setting these flags will enable the IDNA_ALLOW_UNASSIGNED
               (allow unassigned  Unicode  code  points)  and
               IDNA_USE_STD3_ASCII_RULES (check output to make sure
               it is a  STD3  conforming  host  name) flags
               respectively to be used in the IDNA handling.

I would hope that this level of detail would be handled by utility  
functions provided in net/core -- in6_pton, for example.

(Actually net/core should provide appropriate helpers for mapping  
device names to scope_ids, but I didn't find anything like this).

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com--
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