netdev - Re: [PATCH] Bluetooth: 6lowpan: Fix disconnect bug in 6lowpan

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:   Mon, 22 Jan 2018 14:33:59 -0500
From:   Alexander Aring <alex.aring@...il.com>
To:     Luiz Augusto von Dentz <luiz.dentz@...il.com>
Cc:     Guo Yi <yi2010.guo@...sung.com>,
        "linux-bluetooth@...r.kernel.org" <linux-bluetooth@...r.kernel.org>,
        "open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Marcel Holtmann <marcel@...tmann.org>,
        "Gustavo F. Padovan" <gustavo@...ovan.org>,
        Johan Hedberg <johan.hedberg@...il.com>,
        David Miller <davem@...emloft.net>
Subject: Re: [PATCH] Bluetooth: 6lowpan: Fix disconnect bug in 6lowpan

Hi,

2018-01-22 8:00 GMT-05:00 Luiz Augusto von Dentz <luiz.dentz@...il.com>:
> Hi Alex,
>
...
>>
>> or is there a special bluetooth API call needed, like the current case
>> with debugfs.
>> I know hcis are not netdevs, but it bothers me that we running into
>> two different worlds on how to deal with that and it just requires
>> "more" special bluetooth specific handling in user space applications.
>> Later more "netdev" capable link layers will maybe support 6LoWPAN and
>> then bluetooth might the only subsystem where different handling is
>> needed to do such job like that.
>
> Keep in mind that the transport on Bluetooth happens to be in a
> different layer, so you are basically suggesting that the kernel
> maintain a L2CAP connection, similar to TCP, which has several
> security implications.
>

no, I didn't said to change something in protocol handling etc.
I just wanted to say that I am aware that hci is not netdev and it's
hard to use net core api on these "interface types", because net core
knows netdevs only.

>> We maybe need to support a special handling in "ip link add" to map to
>> bluetooth instead moving that to people in user space?
>
> Afaik ip tool cannot support any tunnel interface since the kernel
> cleanup any socket opened when the tool exit. Btw, with the patches
> above bluetoothd would take care of adding/removing the links
> automatically so at least this step will not be necessary. Other ip
> commands should work though.
>

not tunneling, etc. I just want to know how you create a netdev
capable 6LoWPAN interface, it is not done by net core API so far I see
and it will never be done?
You say bluetoothd will care about it, but then bluetoothd will call
the right bluetooth API (not net core API, e.g. netlink (what iproute
uses))
Example:

ip link add link hci0 name 6lo0 type 6lowpan

This cannot work because the net core API will not work on HCI
"devices", I see..., but it highly bothers me that we cannot use
similar API to add or delete such interfaces with netlink API and
iproute2 -> you are forced to use bluetooth API with everything behind
it. At least a delete should work... (I am currently not sure if "ip
link del" would work with bluetooth 6LoWPAN).

According to adding a 6LoWPAN interface, so far I see it will never be
handled by net core API and creating a mapping from net core API to
bluetooth sounds fragile...

At least there is some command "create an 6LoWPAN interface for my
link layer hci device" or it's still magically created/removed by if
there exists a connection or not (I highly don't recommend it, because
user space applications cannot simple deal with dynamically creation
and removal of netdevs (and at the end it should be act like the
removed one again)), ifup/ifdown -> that's okay...
We already had this discussion once if I remember correctly.

- Alex