netdev - Re: mmap RX_RING socket issue 32b application running on 64b kernel.

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: <CAMJ=MEdjyJ8+Y_ZaHkcizy_Y8gdWFoSbz+PdVbYkRDTKyMzT1Q@mail.gmail.com>
Date:	Wed, 7 Nov 2012 19:54:38 +0100
From:	Ronny Meeus <ronny.meeus@...il.com>
To:	Daniel Borkmann <danborkmann@...earbox.net>
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 7:26 PM, Daniel Borkmann
<danborkmann@...earbox.net> wrote:
> 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

I did not try this. I will do it tomorrow.
Thanks for the quick response.
--
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