From nobody Tue Sep 10 19:04:40 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4X3CnC4Lk6z5WT67; Tue, 10 Sep 2024 19:04:47 +0000 (UTC) (envelope-from alnsn@yandex.ru) Received: from forward501d.mail.yandex.net (forward501d.mail.yandex.net [178.154.239.209]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3CnC1c43z4SDZ; Tue, 10 Sep 2024 19:04:47 +0000 (UTC) (envelope-from alnsn@yandex.ru) Authentication-Results: mx1.freebsd.org; none Received: from mail-nwsmtp-smtp-production-main-24.klg.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-24.klg.yp-c.yandex.net [IPv6:2a02:6b8:c42:2d4c:0:640:de18:0]) by forward501d.mail.yandex.net (Yandex) with ESMTPS id 5D0AF608E9; Tue, 10 Sep 2024 22:04:43 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-24.klg.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id e4oBfACoCKo0-nXAlgKWZ; Tue, 10 Sep 2024 22:04:42 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1725995082; bh=3E8FQYsPiOVQqyKRmki79OX4khwQPIv/cFy4p19RpQs=; h=Message-ID:Subject:References:To:From:In-Reply-To:Cc:Date; b=AstHlPfEJDQ59hdwaIZQTCj4D1L3wuaW+vTKo8Y3AZ4vgvq0nOYkvxFbFqOrDzo3V KxGtNabuZWlviT0cvlnfeGzE/S7nIasiIE7yMOfNdfVmzc1I1mTYL+FzC7xbfadNJF /e5akAtRl++SrhgB3XJcVtzTVcoEVOgdeBWXFKJY= Date: Tue, 10 Sep 2024 20:04:40 +0100 From: Alexander Nasonov To: Poul-Henning Kamp Cc: Vadim Goncharov , freebsd-arch@FreeBSD.org, freebsd-hackers@FreeBSD.org, freebsd-net@FreeBSD.org, tech-net@NetBSD.org, Alexander Nasonov Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative Message-ID: References: <20240910040544.125245ad@nuclight.lan> <202409100638.48A6cor2090591@critter.freebsd.dk> <20240910144557.4d95052a@nuclight.lan> <202409101224.48ACO7oj094058@critter.freebsd.dk> <20240910160915.55ff579b@nuclight.lan> <202409101432.48AEWu1q094702@critter.freebsd.dk> List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202409101432.48AEWu1q094702@critter.freebsd.dk> X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:200350, ipnet:178.154.224.0/19, country:RU] X-Rspamd-Queue-Id: 4X3CnC1c43z4SDZ Poul-Henning Kamp wrote: > A) How powerful do you want the downloaded bytecode to be ? ... > There are basically two possible answers to A. > > Either the downloaded code is "real", which means it can include > loops, function calls etc. or it is a "toy" which relies on > Brinch-Hansen's "all arrows point to the right" argument to prove > that it will always terminate. BPF can be easily modified to have functions and calls but it will increase worst case execution complexity to quadratic and the stack growth will have to be watched closely: - always jump forward (within the current function), - always call backwards (outside of the current function). Backward jumps (within the current function) can be implemented with some kind of slowly closing door. For instance, in packet filtering, the first backward jump disables access to the first byte, the second backward jump disables access to the second byte, etc. In general, it will require a special counter but BPFJIT compiler should be able to spot simple loops that process at least one byte on each iteration and minimise runtime overhead. > ... > The answer to that is that you can write them in /any/ programming > language you want, as long as the interpreter for the resulting > (byte-)code an spot attempts to jump backwards, and refuse to > do so, if so configured. I guess it will work for a simple single-pass interpreter that generates bytecode as it reads source code but anything more complicated may reshuffle bytecode and some forward jumps may become backward jumps etc. > And that is why I say: If we're going to do this, let us do > it with Lua: It's already in our tree and it will do the > job nicely. Lua is a good choice, IMO but we likely need a subset of Lua (e.g. no metatables, no C or paused GC with a periodic lua_State rotations to collect garbage). Alex