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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 7 Nov 2012 18:58:55 +0100
From:	Ronny Meeus <>
To:	netdev <>
Subject: mmap RX_RING socket issue 32b application running on 64b kernel.

I have an application using raw Ethernet sockets in combination with
the mmaped RX_RING.
The application is running on a Cavium MIPS processor (64bit) and the
application code is compiled with the N32 ABI.

Since the ring buffer is shared between the Linux kernel and the
application there is a conflict in the way the data is presented.
Each buffer in the ring has a header that has following structure:
(File )
103 struct tpacket_hdr {
104         unsigned long   tp_status;
105         unsigned int    tp_len;
106         unsigned int    tp_snaplen;
107         unsigned short  tp_mac;
108         unsigned short  tp_net;
109         unsigned int    tp_sec;
110         unsigned int    tp_usec;
111 };

The status field indicates that the buffer belongs to the kernel or to
the user. Note that an unsigned long is used to represent the field.
In the kernel the long is 64 bit while in application space the long
is only 32bit, so the bits do not match.

After adapting the code to take this into account my program works well.
In my test program I have defined a new struct where I change the
“unsigned long” into an “unsigned long long”:

struct tpacket_hdr_64 {
  unsigned long long tp_status;
  unsigned int tp_len;
  unsigned int tp_snaplen;
  unsigned short tp_mac;
  unsigned short tp_net;
  unsigned int tp_sec;
  unsigned int tp_usec;

In my opinion this is not a correct solution. It should be solved
somewhere in the include file I used so that it is transparent for the
Please comment.

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists