netdev - Re: [Resend PATCH net] bridge: uapi: mrp: Fix MRP_PORT

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

Message-ID: <20200623080217.bjsml4jmrvrq6eev@soft-dev3.localdomain>
Date:   Tue, 23 Jun 2020 10:02:17 +0200
From:   Horatiu Vultur <horatiu.vultur@...rochip.com>
To:     David Miller <davem@...emloft.net>
CC:     <nikolay@...ulusnetworks.com>, <UNGLinuxDriver@...rochip.com>,
        <linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>
Subject: Re: [Resend PATCH net] bridge: uapi: mrp: Fix MRP_PORT_ROLE

The 06/22/2020 16:07, David Miller wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> From: Horatiu Vultur <horatiu.vultur@...rochip.com>
> Date: Sat, 20 Jun 2020 15:14:03 +0200
> 
> > Currently the MRP_PORT_ROLE_NONE has the value 0x2 but this is in conflict
> > with the IEC 62439-2 standard. The standard defines the following port
> > roles: primary (0x0), secondary(0x1), interconnect(0x2).
> > Therefore remove the port role none.
> >
> > Fixes: 4714d13791f831 ("bridge: uapi: mrp: Add mrp attributes.")
> > Signed-off-by: Horatiu Vultur <horatiu.vultur@...rochip.com>
> 
> The code accepts arbitrary 32-bit values for the role in a configuration
> but only PRIMARY and SECONDARY seem to be valid.
> 
> There is no validation that the value used makes sense.
> 
> In the future if we handle type interconnect, and we add checks, it will
> break any existing applications.  Because they can validly pass any
> non-zero valid and the code treats that as SECONDARY currently.
> 
> So you really can't just remove NONE, you have to add validation code
> too so we don't run into problem in the future.

Thanks for the explanation. I will add some code that checks
specifically for primary(0x0) and secondary(0x1) values and for any
other value to return -EINVAL.
Then in the future when we handle the type interconnect(0x2), we will
just extend this code to check for this value.

> 
> Thanks.

-- 
/Horatiu