From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Hutchings Subject: Re: [PATCH 1/3] bpf/verifier: Log instruction patching when verbose logging is enabled Date: Thu, 29 Nov 2018 15:55:55 +0000 Message-ID: <1543506955.2867.10.camel@codethink.co.uk> References: <20181123183356.5q4bu47zpj5wdufb@xylophone.i.decadent.org.uk> <20181123183455.qjokyt6zpa2yck6s@xylophone.i.decadent.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org To: Daniel Borkmann , Alexei Starovoitov Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Fri, 2018-11-23 at 21:10 +0100, Daniel Borkmann wrote: > On 11/23/2018 07:34 PM, Ben Hutchings wrote: > > User-space does not have access to the patched eBPF code, but we > > need to be able to test that patches are being applied.  Therefore > > log distinct messages for each case that requires patching. > > Thanks for the patches, Ben! Above is actually not the case, e.g. privileged > admin can use something like 'bpftool prog dump xlated id ' and then the > BPF insns are dumped to user space for the program /after/ the verification, > so the rewrites can then be seen. Oh that's good. > test_verifier temporarily drops caps to > load and run the unprivileged cases, but we can extend the test suite to > retrieve and check the final insns after that happened. I think this would be > a nice extension to the test suite for cases like these and would also provide > better insight than verbose() statement saying that something has been > patched (but not the actual result of it). Agreed; I'll look into doing this instead. Ben. -- Ben Hutchings, Software Developer   Codethink Ltd https://www.codethink.co.uk/ Dale House, 35 Dale Street Manchester, M1 2HF, United Kingdom