netdev - Re: [RFC 02/12] net: cls_bpf: add hardware offload

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]

Date:	Wed, 1 Jun 2016 21:59:47 +0100
From:	Jakub Kicinski <jakub.kicinski@...ronome.com>
To:	John Fastabend <john.fastabend@...il.com>
Cc:	netdev@...r.kernel.org, ast@...nel.org, daniel@...earbox.net,
	dinan.gunawardena@...ronome.com
Subject: Re: [RFC 02/12] net: cls_bpf: add hardware offload

On Wed, 1 Jun 2016 10:13:48 -0700, John Fastabend wrote:
> > +static void cls_bpf_stop_offload(struct tcf_proto *tp,
> > +				 struct cls_bpf_prog *prog)
> > +{
> > +	struct net_device *dev = tp->q->dev_queue->dev;
> > +
> > +	if (!prog->offloaded)
> > +		return;
> > +	if (WARN_ON(!tc_should_offload(dev, 0)))
> > +		return;  
> 
> This warn on is a bit concerning it looks like you can get
> a program stuck in hardware but removed from the software
> stack. Any idea why this could happen? I think it is better
> to solve the root problem or just remove this if its dbg code.
> 
> One thought is you need to block disabling the ethtool flag
> if the hardware has running ebpf codes. Haven't got to the
> driver patches yet though so not sure if you did this or not.
> And now that I think about it I better go check the other
> drivers.

Yes, I do refuse clearing the ethtool flag if offload is active.
I put the warning there in an attempt to document that "this should
never happen".  I'll drop it in the next revision.