From nobody Tue Sep 10 14:41:20 2024 X-Original-To: freebsd-hackers@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 4X35xS59cdz5VwYD for ; Tue, 10 Sep 2024 14:41:32 +0000 (UTC) (envelope-from gavin@gavinhoward.com) Received: from mail-40136.proton.ch (mail-40136.proton.ch [185.70.40.136]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X35xQ2yYYz4XPG for ; Tue, 10 Sep 2024 14:41:30 +0000 (UTC) (envelope-from gavin@gavinhoward.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gavinhoward.com header.s=protonmail3 header.b=z2SUQFVi; dmarc=pass (policy=quarantine) header.from=gavinhoward.com; spf=pass (mx1.freebsd.org: domain of gavin@gavinhoward.com designates 185.70.40.136 as permitted sender) smtp.mailfrom=gavin@gavinhoward.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gavinhoward.com; s=protonmail3; t=1725979287; x=1726238487; bh=RW67wIDS5bvUOHOvpr1ZNJ6nwIqNKEwC+/c3JJKCTbg=; h=Date:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=z2SUQFVifKU8tRcBry+p5VQGi32KwoBLA1lAcd5+RdeNwBPEAWDffoLD7elBNNN7c HoY1FwxICh5VVq6nCtUSRvy02L+Lb1FBQU/2ddprPcLxXCDW46Jn1F6xquj/8eB8Hb ARc7hVUZqWaq5tnyA318LP6rJaUkTwbsZtVmlXzExUokFHSjKdomNlWhoVRkkBuwMt kWQ39P9kRgRyqHTWFaI1fUkPS0Ll4lU91wveIuDPFFISLI45QpYiNPdr1Kv2Y/NbBb ecCsCsOELDPXynXwWrAhcWQxZwst5FzVEXBCgW4ypneIVMx25VQiJW7Ec3bM/gTAv8 gw5TRvOlYSUfA== Date: Tue, 10 Sep 2024 14:41:20 +0000 From: "Gavin D. Howard" Cc: freebsd-arch@FreeBSD.org, freebsd-hackers@FreeBSD.org, freebsd-net@FreeBSD.org, tcpdump-workers@lists.tcpdump.org, tech-net@NetBSD.org, Alexander Nasonov Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative Message-ID: In-Reply-To: <20240910040544.125245ad@nuclight.lan> References: <20240910040544.125245ad@nuclight.lan> Feedback-ID: 18790518:user:proton X-Pm-Message-ID: d4caef58d7e64cc697c44701208132b07bb0c1ca List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.19 / 15.00]; MISSING_TO(2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; DMARC_POLICY_ALLOW(-0.50)[gavinhoward.com,quarantine]; RWL_MAILSPIKE_VERYGOOD(-0.20)[185.70.40.136:from]; R_DKIM_ALLOW(-0.20)[gavinhoward.com:s=protonmail3]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; MIME_GOOD(-0.10)[text/plain]; FREEFALL_USER(0.00)[gavin]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gavinhoward.com:+] X-Rspamd-Queue-Id: 4X35xQ2yYYz4XPG Hello, New user here, not a contributor. > Ensuring kernel stability? Just don't allow arbitrary pointers, like orig= inal BPF. > Guaranteed termination time? It's possible if you place some restrictions= . For > example, don't allow backward jumps but allow function calls - in case of > stack overflow, terminate program. Really need backward jumps? Let's anal= yze > for what purpose. You'll find these are needed for loops on packet conten= ts. > Solve it but supporting loops in "hardware"-controlled loops, which can't= be > infinite. If I understand Turing-completeness correctly, the "no backward jumps but allow recursion and quit on stack overflow" is exactly equivalent to having non-infinite loops. I'm not entirely sure, but I think the lack of backwards jumps would be "simple" to check on LLVM IR: just make sure that a basic block does not jump, directly or indirectly, to a basic block that dominates it. [1] [1]: https://en.wikipedia.org/wiki/Dominator_(graph_theory) And then the stack overflow mechanic would be an entirely runtime check, which is safer than pure static checking. But the good thing about this is that FreeBSD could use LLVM IR as the BPF64 language, which means any language that compiles to LLVM is a possible target. As for restricting access, I think it would be possible to check the instructions in LLVM IR for any unsafe instructions or calls to restricted functions. The downsides: * Someone would need to write an LLVM analyze pass or whatever they're called. Maybe more than one. * The kernel would need the ability to compile LLVM IR, making LLVM part of the Ring 0 domain. =09* Either that, or someone builds an LLVM-to-bytecode translator. =09* But the analysis pass(es) must still live in the kernel. * There would need to be tutorials or some docs on how to write whatever language so that backwards jumps are avoided. Please take my words with a full dose of salt; I'm not an expert on this or on FreeBSD goals. Gavin Howard