Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751122AbdFSSLC (ORCPT ); Mon, 19 Jun 2017 14:11:02 -0400 Received: from www62.your-server.de ([213.133.104.62]:50080 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750846AbdFSSLB (ORCPT ); Mon, 19 Jun 2017 14:11:01 -0400 Message-ID: <594813AA.5010001@iogearbox.net> Date: Mon, 19 Jun 2017 20:10:50 +0200 From: Daniel Borkmann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Shubham Bansal CC: Kees Cook , Network Development , "David S. Miller" , Alexei Starovoitov , Russell King , "linux-arm-kernel@lists.infradead.org" , LKML , Andrew Lunn Subject: Re: [PATCH v2] arm: eBPF JIT compiler References: <1495754003-21099-1-git-send-email-illusionist.neo@gmail.com> <593E6B0F.8070901@iogearbox.net> <59419D1E.2060303@iogearbox.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2027 Lines: 48 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 >