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

Message-ID: <CACcJQnRBE4sU6HNvALNdNvr8H-QSo6f41qBXPyTg1qKnmehDPw@mail.gmail.com>
Date:	Fri, 20 Mar 2015 09:45:51 -0700
From:	Anuradha Karuppiah <anuradhak@...ulusnetworks.com>
To:	Alexei Starovoitov <alexei.starovoitov@...il.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: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.

New bits only need to be added if there are new errors that need to be
cleared independent of other applications that can error-disable a
device.
--
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