netdev - Re: [PATCH net 2/2] net/sched: cls_flower: Use masked key when calling HW offloads

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: <20161215154344.GA24984@penelope.horms.nl>
Date:   Thu, 15 Dec 2016 16:43:45 +0100
From:   Simon Horman <simon.horman@...ronome.com>
To:     Or Gerlitz <ogerlitz@...lanox.com>, Jiri Pirko <jiri@...nulli.us>
Cc:     Paul Blakey <paulb@...lanox.com>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        Jiri Pirko <jiri@...lanox.com>, Roi Dayan <roid@...lanox.com>,
        Shahar Klein <shahark@...lanox.com>,
        Hadar Hen Zion <hadarh@...lanox.com>
Subject: Re: [PATCH net 2/2] net/sched: cls_flower: Use masked key when
 calling HW offloads

On Thu, Dec 15, 2016 at 04:12:05PM +0200, Or Gerlitz wrote:
> On 12/15/2016 3:50 PM, Simon Horman wrote:
> >>Zero bits on the mask signify a "don't care" on the corresponding bits
> >>in key. Some HWs require those bits on the key to be zero. Since these
> >>bits are masked anyway, it's okay to provide the masked key to all
> >>drivers.
> >>
> >>Fixes: 5b33f48842fa ('net/flower: Introduce hardware offload support')
> >>
> >While I don't have a specific use case in mind that this change would break
> >it seems to me that it would be better to handle hardware requirements
> >at the driver level.
> 
> Simon, again, since these bits are masked anyway, it would be correct to
> provide the masked key to the hw device.
> 
> E.g no matter if the flow key/mask provided to the HW device is is
> 1.1.1.10/24  or 1.1.1.0/24, the user expects to the same matching, so
> nothing can't happen if we provide the latter to the driver.

> >While I don't have a specific use case in mind that this change would break
> >it seems to me that it would be better to handle hardware requirements
> >at the driver level.
> 
> Even though, makes no sense to pass unmasked key down. Is is only
> confusing. This patch fixes it.

It seems somewhat arbitrary to me to allow such filters in software
but not pass then down to the driver layer. But I don't feel strongly
about this and I am happy for the patch to progress as-is.