netdev - RE: [RFC PATCH v2 1/2] net: af_packet support for direct ring access in user space

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: <063D6719AE5E284EB5DD2968C1650D6D1CAC6BA5@AcuExch.aculab.com>
Date:	Tue, 13 Jan 2015 17:15:30 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'John Fastabend' <john.fastabend@...il.com>,
	Daniel Borkmann <dborkman@...hat.com>
CC:	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"danny.zhou@...el.com" <danny.zhou@...el.com>,
	"nhorman@...driver.com" <nhorman@...driver.com>,
	"john.ronciak@...el.com" <john.ronciak@...el.com>,
	"brouer@...hat.com" <brouer@...hat.com>
Subject: RE: [RFC PATCH v2 1/2] net: af_packet support for direct ring
 access in user space

From: John Fastabend
> On 01/13/2015 05:21 AM, Daniel Borkmann wrote:
> > On 01/13/2015 01:35 PM, Hannes Frederic Sowa wrote:
> >> On Mo, 2015-01-12 at 20:35 -0800, John Fastabend wrote:
> > ...
> >>> +/* setsockopt takes addr, size ,direction parametner, getsockopt takes
> >>> + * iova, size, direction.
> >>> + * */
> >>> +struct tpacket_dma_mem_region {
> >>> +    void *addr;        /* userspace virtual address */
> >>> +    __u64 phys_addr;    /* physical address */
> >>> +    __u64 iova;        /* IO virtual address used for DMA */
> >>> +    unsigned long size;    /* size of region */
> >>> +    int direction;        /* dma data direction */
> >>> +};
> >>
> >> Have you tested this with with 32 bit user space and 32 bit kernel, too?
> >> I don't have any problem with only supporting 64 bit kernels for this
> >> feature, but looking through the code I wonder if we handle the __u64
> >> addresses correctly in all situations.
> 
> We still need to test/implement this I'm going to guess there is some
> more work needed for this to work correctly.

How about something like:

struct tpacket_dma_mem_region {
    __u64 addr;        /* userspace virtual address */
    __u64 phys_addr;    /* physical address */
    __u64 iova;        /* IO virtual address used for DMA */
    __u64 size;    /* size of region */
    int direction;        /* dma data direction */
} aligned(8);

So that it is independant of 32/64 bits.
It is a shame that gcc has no way of defining a 64bit 'void *' on 32bit systems.
You can use a union, but you still need to zero extend the value on LE (worse on BE).

	David