[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87k04mzlc3.fsf@nvidia.com>
Date: Wed, 26 Oct 2022 16:51:32 +0200
From: Petr Machata <petrm@...dia.com>
To: <Daniel.Machon@...rochip.com>
CC: <petrm@...dia.com>, <netdev@...r.kernel.org>,
<davem@...emloft.net>, <maxime.chevallier@...tlin.com>,
<thomas.petazzoni@...tlin.com>, <edumazet@...gle.com>,
<kuba@...nel.org>, <pabeni@...hat.com>,
<Lars.Povlsen@...rochip.com>, <Steen.Hegelund@...rochip.com>,
<UNGLinuxDriver@...rochip.com>, <joe@...ches.com>,
<linux@...linux.org.uk>, <Horatiu.Vultur@...rochip.com>,
<Julia.Lawall@...ia.fr>, <vladimir.oltean@....com>,
<linux-kernel@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [net-next v3 1/6] net: dcb: add new pcp selector to app object
<Daniel.Machon@...rochip.com> writes:
>> I'm missing a validation that DCB_APP_SEL_PCP is always sent in
>> DCB_ATTR_DCB_APP encapsulation. Wouldn't the current code permit
>> sending it in the IEEE encap? This should be forbidden.
>
> Right. Current impl. does not check that the non-std selectors received, are
> sent with a DCB_ATTR_DCB_APP type. We could introduce a new check
> dcbnl_app_attr_selector_validate() that checks combination of type and
> selector, after the type and nla_len(attr) has been checked, so that:
>
> validate type -> validate nla_len(attr) -> validate selector
This needs to be validated, otherwise there's no point in having a
dedicated attribute for the non-standard stuff.
>> And vice versa: I'm not sure we want to permit sending the standard
>> attributes in the DCB encap.
>
> dcbnl_app_attr_type_get() in dcbnl_ieee_fill() takes care of this. IEEE are
> always sent in DCB_ATTR_IEEE and non-std are sent in DCB_ATTR_DCB.
By "sending" I meant userspace sending this to the kernel. So bounce
extended opcodes that are wrapped in IEEE and bounce IEEE opcodes
wrapped in DCB as well.
Powered by blists - more mailing lists