From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from www62.your-server.de (www62.your-server.de [213.133.104.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id AE97D3CB35 for ; Wed, 22 Aug 2018 06:41:41 -0400 (EDT) Received: from [78.46.172.2] (helo=sslproxy05.your-server.de) by www62.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1fsQa2-0007zd-Dz; Wed, 22 Aug 2018 12:41:38 +0200 Received: from [2a02:120b:c3f4:b8b0:b5ea:3969:d380:aafd] (helo=linux.home) by sslproxy05.your-server.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1fsQa2-000PIm-9B; Wed, 22 Aug 2018 12:41:38 +0200 To: =?UTF-8?Q?Toke_H=c3=b8iland-J=c3=b8rgensen?= , Pete Heist Cc: Dave Taht , Cake List References: <20180816164423.14368-1-peterpenkov96@gmail.com> <20180816164423.14368-3-peterpenkov96@gmail.com> <5E9B5665-E115-4B8B-959A-0A4A4220046A@heistp.net> <871saqah2m.fsf@toke.dk> From: Daniel Borkmann Message-ID: <72d4eaa7-e1ae-67c9-98fa-2664d1cd52f9@iogearbox.net> Date: Wed, 22 Aug 2018 12:41:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <871saqah2m.fsf@toke.dk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.100.1/24863/Tue Aug 21 18:48:32 2018) Subject: Re: [Cake] [bpf-next RFC 2/3] flow_dissector: implements eBPF parser X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2018 10:41:41 -0000 On 08/22/2018 11:25 AM, Toke Høiland-Jørgensen wrote: > Pete Heist writes: > >> The eBPF verifier seems fragile to me, where I’d be moving lines of >> code around and getting different error messages in an alien tongue. > > Well, it operates on the byte code and errs on the side of safety. I.e., > if it can't prove your program is safe it is going to reject it. Which > can be less than helpful. > > There's a mode where it can dump its state including the byte code it is > operating at, which can be helpful in figuring out why you get an error. > But it has a way to go yet compared with regular compiler error > messages... :) There's also llvm-objdump which can dump with annotated BPF C code and it allows to match the verifier output line number with it. There's a small example in the doc under LLVM section on how to get there: https://cilium.readthedocs.io/en/latest/bpf/#llvm