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: <CACcJQnRnjuMXqp38qFmX1-ehSoP6aDC4Wk=Mn9e7681CQB=cqg@mail.gmail.com>
Date:	Fri, 20 Mar 2015 14:16:26 -0700
From:	Anuradha Karuppiah <anuradhak@...ulusnetworks.com>
To:	David Miller <davem@...emloft.net>
Cc:	"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 1:28 PM, David Miller <davem@...emloft.net> wrote:
> From: anuradhak@...ulusnetworks.com
> Date: Fri, 20 Mar 2015 08:11:55 -0700
>
>> Applications can detect errors in the network that would require
>> disabling the device independent of the admin state.
>
> I hate changes like this.
>
> The only reason it exists, is because you don't want to put together
> the infrastructure and framework necessary for applications managing
> this state in userspace to _work_ _together_.  So you make it a kernel
> problem.
>
> UP/DOWN is a boolean state, that's not changing.
>
> So you need to design your stuff such that one entity takes all of the
> collective decisions together and calculates the final up/down state,
> and then asks the kernel to do that.
>
> Nothing is more bullshit than having someone ask the kernel to up the
> interface and the thing doesn't come up because of this auxiliary
> crap.  That's broken and nobody is going to expect nor be happy with
> that behavior.

I understand your position on this. And I agree .... ..however, in
this particular case ....

Unfortunately there is no way to distinguish between admin state and
error state in the user space. Currently administrators are directly
using “ip link set up/down”/IFF_UP as a means to admin-enable/disable
a device. So even if we were to consolidate all the errors in the user
space there is no way to error-disable/enable a device without
overriding the administrator’s directive.

What we are looking for is a way for user space to hold the device
down on detecting incorrect config/topology and for enabling the
device once the error condition is removed provided the administrator
didn’t intentionally disable it. And we don't see a way for a user
protocol to do this without involving the kernel.

Thanks for the review.
--
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