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] [day] [month] [year] [list]
Date:	Tue, 29 Dec 2015 12:16:08 -0500
From:	Craig Gallek <kraigatgoog@...il.com>
To:	Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:	netdev@...r.kernel.org, David Miller <davem@...emloft.net>
Subject: Re: [PATCH net-next 3/4] soreuseport: setsockopt SO_ATTACH_REUSEPORT_[CE]BPF

On Sat, Dec 26, 2015 at 2:05 PM, Craig Gallek <kraigatgoog@...il.com> wrote:
> On Thu, Dec 24, 2015 at 11:36 AM, Alexei Starovoitov
> <alexei.starovoitov@...il.com> wrote:
>> On Tue, Dec 22, 2015 at 03:05:09PM -0500, Craig Gallek wrote:
>>> +     /* temporarily advance data past protocol header */
>>> +     if (skb_headlen(skb) < hdr_len || !skb_pull_inline(skb, hdr_len)) {
>>
>> though bpf core will read just fine past linear part of the packet,
>> here we're limiting this feature only to packets where udp header is
>> part of headlen. Will it make it somewhat unreliable?
>> May be we can avoid doing this pull/push and use negative load
>> instructions with SKF_NET_OFF ? Something like:
>> load_word(skb, SKF_NET_OFF + sizeof(struct udphdr)));
> This is an excellent point and will be even more relevant for TCP.
> I'll try to get this to work for v2.
Looking at this more closely, I think the right thing to do is to
simply change the headlen check here to pskb_may_pull.  This mirrors
the behavior in the receive path when pulling headers.  It will also
maintain the convention of passing an skb to the bpf filter with the
data pointer advanced to the payload.
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ