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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 31 Oct 2022 17:24:32 +0100 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: [PATCH net-next v4 2/6] net: dcb: add new apptrust attribute <Daniel.Machon@...rochip.com> writes: >> > + if (ieee[DCB_ATTR_DCB_APP_TRUST_TABLE]) { >> > + u8 selectors[IEEE_8021QAZ_APP_SEL_MAX + 1] = {0}; >> > + struct nlattr *attr; >> > + int nselectors = 0; >> > + u8 selector; >> > + int rem, i; >> > + >> > + if (!ops->dcbnl_setapptrust) { >> > + err = -EOPNOTSUPP; >> > + goto err; >> > + } >> > + >> > + nla_for_each_nested(attr, ieee[DCB_ATTR_DCB_APP_TRUST_TABLE], >> > + rem) { >> > + if (nla_type(attr) != DCB_ATTR_DCB_APP_TRUST || >> > + nla_len(attr) != 1 || >> > + nselectors >= sizeof(selectors)) { >> > + err = -EINVAL; >> > + goto err; >> > + } >> > + >> > + selector = nla_get_u8(attr); >> > + switch (selector) { >> > + case IEEE_8021QAZ_APP_SEL_ETHERTYPE: >> > + case IEEE_8021QAZ_APP_SEL_STREAM: >> > + case IEEE_8021QAZ_APP_SEL_DGRAM: >> > + case IEEE_8021QAZ_APP_SEL_ANY: >> > + case IEEE_8021QAZ_APP_SEL_DSCP: >> > + case DCB_APP_SEL_PCP: >> >> This assumes that the range of DCB attributes will never overlap with >> the range of IEEE attributes. Wasn't the original reason for introducing >> the DCB nest to not have to make this assumption? >> >> I.e. now that we split DCB and IEEE attributes in the APP_TABLE >> attribute, shouldn't it be done here as well? > > Hmm, doesn't hurt to do strict checking here as well. We can even get rid > of the DCB_ATTR_DCB_APP_TRUST attr and just pass DCB_ATTR_DCB_APP and > DCB_ATTR_IEEE_APP? Then use the same functions to do the checking. That would make sense to me.
Powered by blists - more mailing lists