From owner-freebsd-net@FreeBSD.ORG Mon Aug 5 21:46:23 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A03B46E7 for ; Mon, 5 Aug 2013 21:46:23 +0000 (UTC) (envelope-from rmind@netbsd.org) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 72A4E2A0E for ; Mon, 5 Aug 2013 21:46:23 +0000 (UTC) Received: from ws (localhost [IPv6:::1]) by mail.netbsd.org (Postfix) with SMTP id C000D14A1C3; Mon, 5 Aug 2013 21:46:21 +0000 (UTC) Date: Mon, 5 Aug 2013 22:46:02 +0100 From: Mindaugas Rasiukevicius To: Alexander Nasonov Subject: Re: BPF_MISC+BPF_COP and BPF_COPX In-Reply-To: <20130805203549.GA2241@x1000.localdomain> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <20130805203549.GA2241@x1000.localdomain> X-Mailer: mail(1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20130805214621.C000D14A1C3@mail.netbsd.org> Cc: tech-net@netbsd.org, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 21:46:23 -0000 Hello Alex, Let's keep freebsd-net CCed in case there is any interest. Alexander Nasonov wrote: > > I like the idea but I have some questions: > > 1. Why do you need access to scratch memory? Is your goal to keep a > state for C code between cop calls? In this case, you can use > the standard void* pointer technique. You'd need to define special > getter/setter cop functions and they will be slower than getting/setting > scratch memory but it's more important to keep a very clear separation > between C code and bpf code. You'd also need to pass void* to > bpf_filter(9), of course. Yes, I may want to keep the state in the memory store or pass the arguments through it, since the accumulator might not be enough. If you prefer getter and setter to perform a boundary check and enforce uint32_t type, I am fine with that. Although BPF_MEMWORDS constant and words storing 32-bit values stayed since 80s.. it is not going to change. However, abusing void * is wrong. Once bpf_filter(9) is adjusted to take an opaque struct bpf_ctx *, the memory store ought to be moved into it. > 2. Why do you set X to 0 and 0xffffffff? For the out-of-range access, > all other bpf code aborts filter program with code 0. I think it's > better to keep X unchanged. The rationale behind it is that we might want to handle out-of-range in the byte-code without breaking the flow. This can be a valid case for BPF_COPX. Just BPF_RET 0 seems a limitation, but I do not have a strong feeling here. > 3. Can cop "patch" itself or other cop functions at runtime? It'd be > much safe if an array of cop functions was read-only. As an > additional benefit when using bpfjit, you could generate direct calls > for BPF_COP (but not for BPF_COPX) in bpfjit_generate_code(). Yes, I think coprocessor functions should be read-only once set. And the direct call for BPF_COP when using BPF JIT is very much preferred! > > Alex -- Mindaugas