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, 7 Nov 2012 19:26:24 +0100
From:	Daniel Borkmann <danborkmann@...earbox.net>
To:	Ronny Meeus <ronny.meeus@...il.com>
Cc:	netdev <netdev@...r.kernel.org>
Subject: Re: mmap RX_RING socket issue 32b application running on 64b kernel.

On Wed, Nov 7, 2012 at 6:58 PM, Ronny Meeus <ronny.meeus@...il.com> wrote:
> 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 http://lxr.free-electrons.com/source/include/linux/if_packet.h )
> 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
> application.
> Please comment.

Have you tried to use packet_mmap with TPACKET version 2  [1]?

In my understanding, it was introduced because of such issues that you
described.

[1] E.g. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=bbd6ef87c544d88c30e4b762b1b61ef267a7d279
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists