netdev - Re: [PATCH net-next 0/3] net: introduce IFF_PROTO

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

Date:	Fri, 20 Mar 2015 11:50:44 -0700
From:	Alexei Starovoitov <alexei.starovoitov@...il.com>
To:	Anuradha Karuppiah <anuradhak@...ulusnetworks.com>
Cc:	"David S. Miller" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Roopa Prabhu <roopa@...ulusnetworks.com>,
	Andy Gospodarek <gospo@...ulusnetworks.com>,
	Wilson Kok <wkok@...ulusnetworks.com>
Subject: Re: [PATCH net-next 0/3] net: introduce IFF_PROTO_DOWN flag.

On Fri, Mar 20, 2015 at 9:45 AM, Anuradha Karuppiah
<anuradhak@...ulusnetworks.com> wrote:
> On Fri, Mar 20, 2015 at 9:13 AM, Alexei Starovoitov
> <alexei.starovoitov@...il.com> wrote:
>> On Fri, Mar 20, 2015 at 8:11 AM,  <anuradhak@...ulusnetworks.com> wrote:
>>> From: Anuradha Karuppiah <anuradhak@...ulusnetworks.com>
>>>
>>> Applications can detect errors in the network that would require
>>> disabling the device independent of the admin state. In the presence of
>>> these errors traffic could be black holed or looped resulting in a
>>> network meltdown. Clearing the IFF_UP flag for error disabling the
>>> device can be problematic because -
>>>
>>> 1. The administrator cannot distinguish between a user space daemon’s
>>> error-disable and a regular device disable.
>>> 2. Applications can monitor the error state and enable the device once
>>> the error is removed. If IFF_UP is used for this purpose the application
>>> may end up enabling a device that the administrator has intentionally
>>> disabled for other reasons. This could result in network changes not
>>> expected by the admin.
>>>
>>
>> Both reasons look like workaround for user space issues.
>> Just keep this fake-down state in userspace.
>> What's the point pushing it to kernel?
>
> Applications can deal with IFF_UP being cleared and they can certainly
> clear IFF_UP as well on detecting errors. However an application
> cannot know the reason for the !IFF_UP notification. So if an
> application detected a device error being cleared it would have to
> unconditionally enable the device as a part of recovery handling
> thereby ignoring the administrator’s request to keep the device
> disabled. Separating error-disable (IFF_PROTO_DOWN) from admin-disable
> (!IFF_UP) lets the administrator have a say in keeping a device
> disabled.
>
>> looking at 3rd patch:
>> + * @IF_LINK_PROTO_DOWN_MLAG: proto_down by a multi-chassis LAG application.
>> + * @IF_LINK_PROTO_DOWN_STP: proto_down by an STP application.
>>
>> so there will be new flag for every application that cannot deal with
>> normal down?
>
> These applications can clear the error state independent of each
> other. Say for e.g.  both STP-BPDU guard and MLAG error-disabled a
> device. When the MLAG split-brain error is resolved the MLAG
> application could clear IFF_PROTO_DOWN but the BPDU guard error would
> still exist. This will create problem windows that could aggressively
> affect the network.
>

if I understand this correctly you have implementation of
stp-bpdu guard in user space instead of bridge stp core and
that is causing these issues. If you move this feature into
the kernel you won't have to add this special down state, right?
--
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