linux-kernel - Re: [PATCH v2] arm: eBPF JIT compiler

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]

Date:   Mon, 19 Jun 2017 20:10:50 +0200
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Shubham Bansal <illusionist.neo@...il.com>
CC:     Kees Cook <keescook@...omium.org>,
        Network Development <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Alexei Starovoitov <ast@...nel.org>,
        Russell King <linux@...linux.org.uk>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        LKML <linux-kernel@...r.kernel.org>, Andrew Lunn <andrew@...n.ch>
Subject: Re: [PATCH v2] arm: eBPF JIT compiler

On 06/17/2017 02:23 PM, Shubham Bansal wrote:
> Hi Daniel,
>
>> Not all of the helpers have 4 or less byte arguments only, there are a
>> few with 8 byte arguments, so making that general assumption wouldn't
>> work. I guess what could be done is that helpers have a flag in struct
>> bpf_func_proto which indicates for JITs that all args are 4 byte on 32bit
>> so you could probably use convention similar to case2 for them. Presumably
>> for that information to process, the JIT might need to be reworked to
>> extract that via bpf_analyzer() that does a verifier run to re-analyze
>> the program like in nfp JIT case.
>
> Let me try a better solution which can be used to support both 4 byte
> and 8 byte arguments. I hope it would work out. Are you sure this
> patch can pass if it only supports 4 byte arguments though?
> Let me list out what I have to do, so that you can tell me if I am
> thinking in a wrong way :-
>
> * I will add a bit flag in bpf_func_proto to represent whether
> different arguments in a function call are 4 bytes or 8 bytes. If lsb
> of bit flag is set then first argument is 8 byte, otherwise its not. I
> think I can handle this flag properly in build_insn() in my code. Does
> this sound okay?
>
> I don't understand second part of your solution, i.e.
>
>> Presumably
>> for that information to process, the JIT might need to be reworked to
>> extract that via bpf_analyzer() that does a verifier run to re-analyze
>> the program like in nfp JIT case.
>
> Please explain what are you suggesting and how can I extract bit flag
> from bpf_func_proto().
>
> Please reply asap, as I would like to finish it over the weekend. Please.

Sorry, had a travel over the weekend, so didn't read it in time.

What is the issue with imitating in JIT what the interpreter is
doing as a starting point? That should be generic enough to handle
any case.

Otherwise you'd need some sort of reverse mapping since verifier
already converted BPF_CALL insns into relative helper addresses
in imm part.

> -Shubham
>