netdev - Re: pull-request: bpf 2018-03-08

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]

Message-ID: <c14a629b-e0c1-7ad5-9562-d87c6d7e383a@iogearbox.net>
Date:   Thu, 8 Mar 2018 02:44:55 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     David Miller <davem@...emloft.net>
Cc:     ast@...nel.org, netdev@...r.kernel.org
Subject: Re: pull-request: bpf 2018-03-08

On 03/08/2018 02:31 AM, David Miller wrote:
> From: Daniel Borkmann <daniel@...earbox.net>
> Date: Thu,  8 Mar 2018 02:17:16 +0100
> 
>> The following pull-request contains BPF updates for your *net* tree.
>>
>> The main changes are:
>>
>> 1) Fix various BPF helpers which adjust the skb and its GSO information
>>    with regards to SCTP GSO. The latter is a special case where gso_size
>>    is of value GSO_BY_FRAGS, so mangling that will end up corrupting
>>    the skb, thus bail out when seeing SCTP GSO packets, from Daniel(s).
>>
>> 2) Fix a compilation error in bpftool where BPF_FS_MAGIC is not defined
>>    due to too old kernel headers in the system, from Jiri.
>>
>> 3) Increase the number of x64 JIT passes in order to allow larger images
>>    to converge instead of punting them to interpreter or having them
>>    rejected when the interpreter is not built into the kernel, from Daniel.
>>
>> Please consider pulling these changes from:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
> 
> Pulled, thanks Daniel.

Thanks!

> About that x86 JIT passes thing...
> 
> I think since you now have a scheduling point in there, you can be
> even more liberal with the limit if necessary.

Agree, if needed we can always adapt it further in future, I think 20
should be good for now.

Thanks,
Daniel