netdev - Re: [PATCH 1/4] net: if_arp: add ARPHRD

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]

Message-ID: <20210625060411.23853-1-rocco.yue@mediatek.com>
Date:   Fri, 25 Jun 2021 14:04:11 +0800
From:   Rocco Yue <rocco.yue@...iatek.com>
To:     Dan Williams <dcbw@...hat.com>
CC:     Greg KH <gregkh@...uxfoundation.org>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Jonathan Corbet <corbet@....net>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        David Ahern <dsahern@...nel.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Felix Fietkau <nbd@....name>, John Crispin <john@...ozen.org>,
        Sean Wang <sean.wang@...iatek.com>,
        Mark Lee <Mark-MC.Lee@...iatek.com>, <netdev@...r.kernel.org>,
        <linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-mediatek@...ts.infradead.org>, <bpf@...r.kernel.org>,
        <wsd_upstream@...iatek.com>, <chao.song@...iatek.com>,
        <kuohong.wang@...iatek.com>, Rocco Yue <rocco.yue@...iatek.com>
Subject: Re: [PATCH 1/4] net: if_arp: add ARPHRD_PUREIP type

On Thu, 2021-06-24 at 11:14 -0500, Dan Williams wrote:
On Thu, 2021-06-24 at 14:13 +0800, Rocco Yue wrote:
>> On Thu, 2021-06-24 at 07:29 +0200, Greg KH wrote:
>> 
>> Before kernel-4.18, RAWIP was the same as PUREIP, neither of them
>> automatically generates an IPv6 link-local address, and the way to
>> generate an IPv6 global address is the same.
> 
> This distinction seems confusing from a kernel standpoint if it only
> changes how v6 IIDs are determined. Do we really need something that's

Hi Dan,

Thanks for your comment,

In the cellular network, v6 IID is important, If the device use the
link-local address formed by the incorrect IID to send RS message to
the network, based on 3GPP, GGSN will not reply solicited RA message.
It will lead to the device can get ipv6 address prefix and ipv6 route.

Maybe the table below is a little bit clearer

three device type: ARPHRD_RAWIP , ARPHRD_PUREIP, ARPHRD_NONE
three mode: IN6_ADDR_GEN_MODE_EUI64 , IN6_ADDR_GEN_MODE_NONE, IN6_ADDR_GEN_MODE_STABLE_PRIVACY

ipv6 link-local address generate behavior in the kernel:
+---------+-------------------+---------------------+----------------+
|         | MODE_EUI64        | MODE_STABLE_PRIVACY | MODE_NONE      |
+---------+-------------------+---------------------+----------------+
| RAWIP   | fe80::(eui64-id)  | fe80::(privacy-id)  | no address gen |
+---------+-------------------+---------------------+----------------+
| PUREIP  | no address gen    | no address gen      | no address gen |
+---------+-------------------+---------------------+----------------+
| NONE    | fe80::(random-id) | fe80::(privacy-id)  | no address gen |
+---------+-------------------+---------------------+----------------+

ipv6 global address generate behavior in the kernel:
+---------+-------------------+---------------------+-------------------+
|         | MODE_EUI64        | MODE_STABLE_PRIVACY | MODE_NONE         |   
+---------+-------------------+---------------------+-------------------+
| RAWIP   | prefix+(eui64-id) | prefix+(privacy-id) | prefix+(eui64-id) |
+---------+-------------------+---------------------+-------------------+
| PUREIP  | prefix+(GGSN-id)  | prefix+(privacy-id) | prefix+(GGSN-id)  |
+---------+-------------------+---------------------+-------------------+
| NONE    | prefix+(random-id)| prefix+(privacy-id) | prefix+(random-id)|
+---------+-------------------+---------------------+-------------------+

> also reflected to userspace (in struct ifinfomsg -> ifi_type) if the
> kernel is handling the behavior that's different? Why should userspace
> care?
> 

In my opinion, userspace program cares about it because the kernel behaves
differently for different device types.
userspace can get the device type of the interface through ioctl, such as
the following code weblink:
https://cs.android.com/android/platform/superproject/+/master:system/netd/server/OffloadUtils.cpp;drc=master;l=41?q=ARPHRD_RAWIP&ss=android%2Fplatform%2Fsuperproject&start=11

> I'm also curious why this isn't an issue for the ipa/rmnet (Qualcomm)
> modem drivers. There's probably a good reason, but would be good to
> know what that is from Alex Elder or Loic or Bjorn...
> 
> Dan

MediaTek and Qualcomm has different hardware or modem design.
For the MediaTek platform, device send the RS message that generated by
the kernel to the GGSN.

Thanks,
Rocco