From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752161AbdFTQz1 (ORCPT ); Tue, 20 Jun 2017 12:55:27 -0400 Received: from www62.your-server.de ([213.133.104.62]:57352 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751028AbdFTQzZ (ORCPT ); Tue, 20 Jun 2017 12:55:25 -0400 Message-ID: <59495367.3080402@iogearbox.net> Date: Tue, 20 Jun 2017 18:55:03 +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> <594813AA.5010001@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 On 06/20/2017 03:34 AM, Shubham Bansal wrote: > Hi Daniel, > >> 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. Why not proceeding this way first? >> Otherwise you'd need some sort of reverse mapping since verifier >> already converted BPF_CALL insns into relative helper addresses >> in imm part. >> > Sorry but I don't get what you are trying to say. Can you explain it > with an example? Ok, probably the best is to check fixup_bpf_calls() in the verifier, see the fn = prog->aux->ops->get_func_proto(insn->imm). It fetches the helper function specification based on the BPF_FUNC_* enum and converts the imm field into a relative address for the function such that if you look at ___bpf_prog_run(), JMP_CALL label, the call address can be reconstructed again. So you'd need some reverse mapping to get back to the struct bpf_func_proto, so you can check argX_type that needs to be extended with whether its JITable on 32bit or not. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Borkmann Subject: Re: [PATCH v2] arm: eBPF JIT compiler Date: Tue, 20 Jun 2017 18:55:03 +0200 Message-ID: <59495367.3080402@iogearbox.net> References: <1495754003-21099-1-git-send-email-illusionist.neo@gmail.com> <593E6B0F.8070901@iogearbox.net> <59419D1E.2060303@iogearbox.net> <594813AA.5010001@iogearbox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Kees Cook , Network Development , "David S. Miller" , Alexei Starovoitov , Russell King , "linux-arm-kernel@lists.infradead.org" , LKML , Andrew Lunn To: Shubham Bansal Return-path: Received: from www62.your-server.de ([213.133.104.62]:57352 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751028AbdFTQzZ (ORCPT ); Tue, 20 Jun 2017 12:55:25 -0400 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On 06/20/2017 03:34 AM, Shubham Bansal wrote: > Hi Daniel, > >> 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. Why not proceeding this way first? >> Otherwise you'd need some sort of reverse mapping since verifier >> already converted BPF_CALL insns into relative helper addresses >> in imm part. >> > Sorry but I don't get what you are trying to say. Can you explain it > with an example? Ok, probably the best is to check fixup_bpf_calls() in the verifier, see the fn = prog->aux->ops->get_func_proto(insn->imm). It fetches the helper function specification based on the BPF_FUNC_* enum and converts the imm field into a relative address for the function such that if you look at ___bpf_prog_run(), JMP_CALL label, the call address can be reconstructed again. So you'd need some reverse mapping to get back to the struct bpf_func_proto, so you can check argX_type that needs to be extended with whether its JITable on 32bit or not. From mboxrd@z Thu Jan 1 00:00:00 1970 From: daniel@iogearbox.net (Daniel Borkmann) Date: Tue, 20 Jun 2017 18:55:03 +0200 Subject: [PATCH v2] arm: eBPF JIT compiler In-Reply-To: References: <1495754003-21099-1-git-send-email-illusionist.neo@gmail.com> <593E6B0F.8070901@iogearbox.net> <59419D1E.2060303@iogearbox.net> <594813AA.5010001@iogearbox.net> Message-ID: <59495367.3080402@iogearbox.net> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 06/20/2017 03:34 AM, Shubham Bansal wrote: > Hi Daniel, > >> 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. Why not proceeding this way first? >> Otherwise you'd need some sort of reverse mapping since verifier >> already converted BPF_CALL insns into relative helper addresses >> in imm part. >> > Sorry but I don't get what you are trying to say. Can you explain it > with an example? Ok, probably the best is to check fixup_bpf_calls() in the verifier, see the fn = prog->aux->ops->get_func_proto(insn->imm). It fetches the helper function specification based on the BPF_FUNC_* enum and converts the imm field into a relative address for the function such that if you look at ___bpf_prog_run(), JMP_CALL label, the call address can be reconstructed again. So you'd need some reverse mapping to get back to the struct bpf_func_proto, so you can check argX_type that needs to be extended with whether its JITable on 32bit or not.