netdev - Re: [RFC PATCH 02/14] packet: implement PACKET

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: <CAJ+HfNjmjoPQ-X=fRhvcQFX_K15BgDBzXpCcQ0X4n3e4VNw16g@mail.gmail.com>
Date:   Fri, 3 Nov 2017 10:57:49 +0100
From:   Björn Töpel <bjorn.topel@...il.com>
To:     Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc:     "Karlsson, Magnus" <magnus.karlsson@...el.com>,
        Alexander Duyck <alexander.h.duyck@...el.com>,
        Alexander Duyck <alexander.duyck@...il.com>,
        John Fastabend <john.fastabend@...il.com>,
        Alexei Starovoitov <ast@...com>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        michael.lundkvist@...csson.com, ravineet.singh@...csson.com,
        Daniel Borkmann <daniel@...earbox.net>,
        Network Development <netdev@...r.kernel.org>,
        Björn Töpel <bjorn.topel@...el.com>,
        jesse.brandeburg@...el.com, anjali.singhai@...el.com,
        rami.rosen@...el.com, jeffrey.b.shaw@...el.com,
        ferruh.yigit@...el.com, qi.z.zhang@...el.com
Subject: Re: [RFC PATCH 02/14] packet: implement PACKET_MEMREG setsockopt

2017-11-03 4:00 GMT+01:00 Willem de Bruijn <willemdebruijn.kernel@...il.com>:
> On Tue, Oct 31, 2017 at 9:41 PM, Björn Töpel <bjorn.topel@...il.com> wrote:
>> From: Björn Töpel <bjorn.topel@...el.com>
>>
>> Here, the PACKET_MEMREG setsockopt is implemented for the AF_PACKET
>> protocol family. PACKET_MEMREG allows the user to register memory
>> regions that can be used by AF_PACKET V4 as packet data buffers.
>>
>> Signed-off-by: Björn Töpel <bjorn.topel@...el.com>
>> ---
>> +/*************** V4 QUEUE OPERATIONS *******************************/
>> +
>> +/**
>> + * tp4q_umem_new - Creates a new umem (packet buffer)
>> + *
>> + * @addr: The address to the umem
>> + * @size: The size of the umem
>> + * @frame_size: The size of each frame, between 2K and PAGE_SIZE
>> + * @data_headroom: The desired data headroom before start of the packet
>> + *
>> + * Returns a pointer to the new umem or NULL for failure
>> + **/
>> +static inline struct tp4_umem *tp4q_umem_new(unsigned long addr, size_t size,
>> +                                            unsigned int frame_size,
>> +                                            unsigned int data_headroom)
>> +{
>> +       struct tp4_umem *umem;
>> +       unsigned int nframes;
>> +
>> +       if (frame_size < TP4_UMEM_MIN_FRAME_SIZE || frame_size > PAGE_SIZE) {
>> +               /* Strictly speaking we could support this, if:
>> +                * - huge pages, or*
>> +                * - using an IOMMU, or
>> +                * - making sure the memory area is consecutive
>> +                * but for now, we simply say "computer says no".
>> +                */
>> +               return ERR_PTR(-EINVAL);
>> +       }
>> +
>> +       if (!is_power_of_2(frame_size))
>> +               return ERR_PTR(-EINVAL);
>> +
>> +       if (!PAGE_ALIGNED(addr)) {
>> +               /* Memory area has to be page size aligned. For
>> +                * simplicity, this might change.
>> +                */
>> +               return ERR_PTR(-EINVAL);
>> +       }
>> +
>> +       if ((addr + size) < addr)
>> +               return ERR_PTR(-EINVAL);
>> +
>> +       nframes = size / frame_size;
>> +       if (nframes == 0)
>> +               return ERR_PTR(-EINVAL);
>> +
>> +       data_headroom = ALIGN(data_headroom, 64);
>> +
>> +       if (frame_size - data_headroom - TP4_KERNEL_HEADROOM < 0)
>> +               return ERR_PTR(-EINVAL);
>
> signed comparison on unsigned int

Thanks, will address in next revision!