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:	Fri, 8 Apr 2016 10:04:25 -0700
From:	Brenden Blanco <bblanco@...mgrid.com>
To:	Jesper Dangaard Brouer <brouer@...hat.com>
Cc:	davem@...emloft.net, netdev@...r.kernel.org, tom@...bertland.com,
	alexei.starovoitov@...il.com, ogerlitz@...lanox.com,
	daniel@...earbox.net, eric.dumazet@...il.com, ecree@...arflare.com,
	john.fastabend@...il.com, tgraf@...g.ch, johannes@...solutions.net,
	eranlinuxmellanox@...il.com, lorenzo@...gle.com
Subject: Re: [RFC PATCH v2 4/5] mlx4: add support for fast rx drop bpf program

On Fri, Apr 08, 2016 at 01:41:58PM +0200, Jesper Dangaard Brouer wrote:
> 
> On Thu,  7 Apr 2016 21:48:49 -0700 Brenden Blanco <bblanco@...mgrid.com> wrote:
> 
> > +int mlx4_call_bpf(struct bpf_prog *prog, void *data, unsigned int length)
> > +{
> > +	struct sk_buff *skb = this_cpu_ptr(&percpu_bpf_phys_dev_md);
> > +	int ret;
> > +
> > +	build_bpf_phys_dev_md(skb, data, length);
> > +
> > +	rcu_read_lock();
> > +	ret = BPF_PROG_RUN(prog, (void *)skb);
> > +	rcu_read_unlock();
> > +
> > +	return ret;
> > +}
> [...]
> 
> > diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> > index 86bcfe5..287da02 100644
> > --- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> > +++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> > @@ -840,6 +843,23 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
> >  		l2_tunnel = (dev->hw_enc_features & NETIF_F_RXCSUM) &&
> >  			(cqe->vlan_my_qpn & cpu_to_be32(MLX4_CQE_L2_TUNNEL));
> >  
> > +		/* A bpf program gets first chance to drop the packet. It may
> > +		 * read bytes but not past the end of the frag.
> > +		 */
> > +		if (prog) {
> > +			struct ethhdr *ethh;
> > +			dma_addr_t dma;
> > +
> > +			dma = be64_to_cpu(rx_desc->data[0].addr);
> > +			dma_sync_single_for_cpu(priv->ddev, dma, sizeof(*ethh),
> > +						DMA_FROM_DEVICE);
> > +			ethh = page_address(frags[0].page) +
> > +							frags[0].page_offset;
> > +			if (mlx4_call_bpf(prog, ethh, frags[0].page_size) ==
> > +							BPF_PHYS_DEV_DROP)
> > +				goto next;
> > +		}
> > +
> 
> Do the program need to know if the packet-page we handover is
> considered 'read-only' at the call site?  Or do we rely on my idea
> requiring the registration to "know" this...
Seems that we're leaning towards the latter at this point. In either
case, we won't allow buggy situations, and let's see which approach
works better when we have RFC code in hand.
> 
> -- 
> Best regards,
>   Jesper Dangaard Brouer
>   MSc.CS, Principal Kernel Engineer at Red Hat
>   Author of http://www.iptv-analyzer.org
>   LinkedIn: http://www.linkedin.com/in/brouer

Powered by blists - more mailing lists