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, 12 Sep 2022 07:03:24 +0000 From: <Daniel.Machon@...rochip.com> To: <vladimir.oltean@....com> CC: <netdev@...r.kernel.org>, <Allan.Nielsen@...rochip.com>, <UNGLinuxDriver@...rochip.com>, <maxime.chevallier@...tlin.com>, <petrm@...dia.com>, <kuba@...nel.org>, <vinicius.gomes@...el.com>, <thomas.petazzoni@...tlin.com> Subject: Re: [RFC PATCH net-next 2/2] net: dcb: add new apptrust attribute Den Fri, Sep 09, 2022 at 12:29:50PM +0000 skrev Vladimir Oltean: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > Hi Daniel, > > On Thu, Sep 08, 2022 at 02:04:42PM +0200, Daniel Machon wrote: > > Add a new apptrust extension attribute to the 8021Qaz APP managed > > object. > > > > The new attribute is meant to allow drivers, whose hw supports the > > notion of trust, to be able to set whether a particular app selector is > > to be trusted - and also the order of precedence of selectors. > > > > A new structure ieee_apptrust has been created, which contains an array > > of selectors, where lower indexes has higher precedence. > > > > Signed-off-by: Daniel Machon <daniel.machon@...rochip.com> > > --- > > Let's say I have a switch which only looks at VLAN PCP/DEI if the bridge > vlan_filtering setting is enabled (otherwise, the switch is completely > VLAN unaware, including for QoS purposes). > > Would it be ok to report through ieee_getapptrust() that the PCP > selector is trusted when under a vlan_filtering bridge, not trusted when > not under a vlan_filtering bridge, and deny changes to ieee_setapptrust() > for the PCP selector? I see the return value is not cached anywhere > within the kernel, just passed to the user. There *might* be a distinction between enabled and trusted, disabled and not-trusted. For instance, sparx5 switch has this distinction (at least for dscp) - but really that is hw dependent. Therefore, in your particular case, with the vlan_filtering on/off, yes that would be OK IMO. Any concerns? This patch merely provides the means for drivers to implement a user-specified trust order and report it back to the user, just like with many of the other dcb attributes (maxrate, buffer etc.).
Powered by blists - more mailing lists