<div dir="ltr"><div class="gmail_extra"><br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

1)<br>
<br>
I took a brief look at arch/x86/net/bpf_jit_comp.c while reviewing this<br>
patch.<br>
<br>
You need to split up bpf_jit_compile(), it's an obscenely large, ~600<br>
lines long function. We don't do that in modern, maintainable kernel code.<br>
<br>
2)<br>
<br>
This 128 bytes extra padding:<br>
<br>
        /* Most of BPF filters are really small,<br>
         * but if some of them fill a page, allow at least<br>
         * 128 extra bytes to insert a random section of int3<br>
         */<br>
        sz = round_up(proglen + sizeof(*header) + 128, PAGE_SIZE);<br>
<br>
why is it done? It's not clear to me from the comment.<br></blockquote><div><br></div><div>commit 314beb9bcabfd6b4542ccbced2402af2c6f6142a</div><div>Author: Eric Dumazet <<a href="mailto:edumazet@google.com">edumazet@google.com</a>></div>
<div>Date:   Fri May 17 16:37:03 2013 +0000</div><div><br></div><div>    x86: bpf_jit_comp: secure bpf jit against spraying attacks</div><div>    </div><div>    hpa bringed into my attention some security related issues</div>
<div>    with BPF JIT on x86.</div><div>    </div><div>    This patch makes sure the bpf generated code is marked read only,</div><div>    as other kernel text sections.</div><div>    </div><div>    It also splits the unused space (we vmalloc() and only use a fraction of</div>
<div>    the page) in two parts, so that the generated bpf code not starts at a</div><div>    known offset in the page, but a pseudo random one.</div><div>    </div><div>    Refs:</div><div>    <a href="http://mainisusuallyafunction.blogspot.com/2012/11/attacking-hardened-linux-systems-with.html">http://mainisusuallyafunction.blogspot.com/2012/11/attacking-hardened-linux-systems-with.html</a></div>
<div>    </div><div> </div></div></div></div>