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: <20171002140723.7667a9b4@redhat.com>
Date:   Mon, 2 Oct 2017 14:07:23 +0200
From:   Jesper Dangaard Brouer <brouer@...hat.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     netdev@...r.kernel.org, jakub.kicinski@...ronome.com,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Jason Wang <jasowang@...hat.com>, mchan@...adcom.com,
        John Fastabend <john.fastabend@...il.com>,
        peter.waskiewicz.jr@...el.com,
        Daniel Borkmann <borkmann@...earbox.net>,
        Andy Gospodarek <andy@...yhouse.net>, brouer@...hat.com
Subject: Re: [net-next V2 PATCH 5/5] samples/bpf: add cpumap sample program
 xdp_redirect_cpu

On Fri, 29 Sep 2017 20:06:09 -0700
Alexei Starovoitov <alexei.starovoitov@...il.com> wrote:

> > +/*** Trace point code ***/
> > +
> > +/* Tracepoint format: /sys/kernel/debug/tracing/events/xdp/xdp_redirect/format
> > + * Code in:                kernel/include/trace/events/xdp.h
> > + */
> > +struct xdp_redirect_ctx {
> > +	unsigned short common_type;	//	offset:0;  size:2; signed:0;
> > +	unsigned char common_flags;	//	offset:2;  size:1; signed:0;
> > +	unsigned char common_preempt_count;//	offset:3;  size:1; signed:0;
> > +	int common_pid;			//	offset:4;  size:4; signed:1;  
> 
> this part is not right. First 8 bytes are not accessible by bpf code.
> Please use __u64 pad; or similar here.

I've corrected this in V3.

Can you explain why BPF cannot access these (first 8 bytes) struct members?


> Just noticed that samples/bpf/xdp_monitor_kern.c has the same problem.
> 
> > +
> > +	int prog_id;			//	offset:8;  size:4; signed:1;
> > +	u32 act;			//	offset:12  size:4; signed:0;
> > +	int ifindex;			//	offset:16  size:4; signed:1;
> > +	int err;			//	offset:20  size:4; signed:1;
> > +	int to_ifindex;			//	offset:24  size:4; signed:1;
> > +	u32 map_id;			//	offset:28  size:4; signed:0;
> > +	int map_index;			//	offset:32  size:4; signed:1;
> > +};					//	offset:36  
> 
> the second part of fields is correct.


-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ