From nobody Tue Sep 10 14:29:19 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 4X35gT2FPTz5VtlY; Tue, 10 Sep 2024 14:29:25 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X35gT1Kzyz4S4b; Tue, 10 Sep 2024 14:29:25 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725978565; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=s3GEIp6Pm27U5X0WQLnTgbvAeltQZEvg1PejEPUlfp4=; b=cvzKdpS4y/XM6wOWOoHbMXAfIppBsl9X8BwqQ7AAqXW9pzvE+Mh62dMSLS4zmRQFjqS7TC rJeGxdzDesn8wxJ9WriGDftWQ3/eScH7FuaOtfSyvY1CstweHpu+twpgaBSK+C2z+STb9j PYhDr9+p6ZfHxcw1iCHoGrUkXddxcBjtL62/ZBH7R8ATRpSyB7gHuTcWFYy1IW7JnDM/4d fidKR9umuA/kYDU126QBHKYfHg/n+JXg/G+FFasoY9dHwcGFlcIDmdUH5hJCcFl/ZAMMUM U4OhAeef162Db9/sXDHWiPK9DS7thAOdoDc1VzdvwOKa7U9/OYJ7bHka09AbvQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725978565; a=rsa-sha256; cv=none; b=Fq/+YRBojozG5185gbYrB4r+d2lR0/MQva7scfwLKpaTniOKBoEEozKQosyfIe3k9/fiOg iUfKTPTiC2gc4XKgS6rZcl8777Or5eSd2ogz8WOQWDz/mW466GvmI9LRqJ9v8AQK3VYAgL JameTunSlRMuBT9YYhBa1Mc2Pkp4M3JYtDWJgC05N3hqiPdgwy1wsx8AidE3a8vxjuaM0g 00dUPQmsCdmYI6rrJeRNEFOjFP58tIayCoAu4H/T7nqk+LZVLhj3X0Lq8UcGzJBZC0agCT wLRRp7/KieJOK+CnoTX0pkuGsn2cIv+WlLFbinc+SISv/zfMczKicT1QL28CDw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725978565; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=s3GEIp6Pm27U5X0WQLnTgbvAeltQZEvg1PejEPUlfp4=; b=Ra7qVGw7JRrPb3O11lG8B9ZCMgsWRLRnu+hxI9LzTpoMvXWrXHoVaNHjaoKCogDwhCeeox EkKSXQXELolYnR7SnAAhu1hA0ynYmsNTaxFTiDUHlJpmcPsr5LJZiFVloRfW1IOzlRaBqE 82PXpn0ggAO8bPlZF8AY9f+p3qHYIE/W173ykWFViTdNQu8Ayh+QIQHWW20y+ds80B1i/P UsOkNKeHV4pyrsxNNh9U7T0IjzD7otF8lke3h6Hoqt1QDJLr5XQNXCYuC57hig7zUcDwH8 LqzrUhQbcfzifoP/XyKQOD6VLnLplPUz9DBuYk8klPkqbBafjnlfGogNDPE5hg== Received: from ralga.knownspace (ip-163-182-7-56.dynamic.fuse.net [163.182.7.56]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhibbits) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X35gS5DtpzSJp; Tue, 10 Sep 2024 14:29:24 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) Date: Tue, 10 Sep 2024 10:29:19 -0400 From: Justin Hibbits To: David Chisnall Cc: Vadim Goncharov , Poul-Henning Kamp , tcpdump-workers@lists.tcpdump.org, "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: <20240910102919.7d8927d0@ralga.knownspace> In-Reply-To: <4D84AF55-51C7-4C2B-94F7-D486A29E8821@FreeBSD.org> References: <20240910040544.125245ad@nuclight.lan> <202409100638.48A6cor2090591@critter.freebsd.dk> <20240910144557.4d95052a@nuclight.lan> <4D84AF55-51C7-4C2B-94F7-D486A29E8821@FreeBSD.org> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.43; powerpc64le-unknown-linux-gnu) 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 On Tue, 10 Sep 2024 13:59:02 +0100 David Chisnall wrote: > On 10 Sep 2024, at 12:45, Vadim Goncharov > wrote: > >=20 > > It's easy for your Lua code (or whatever) code to hang kernel by > > infinite loop. Or crash it by access on arbitrary pointer. That's > > why original BPF has no backward jumps and memory access, and eBPF's > > nightmare verifier walks all code paths and check pointers. =20 >=20 > I=E2=80=99m not convinced by the second: Lua has a GC=E2=80=99d heap, you= =E2=80=99d need to > expose FFI things to it that did unsafe things, and that=E2=80=99s equall= y a > problem for eBPF. >=20 > The first is not a problem. The Lua interpreter has a bytecode > limit. You can define a bounded number of bytecodes that it will > execute. The problem comes from the standard library. Things like > string.gmatch can have high-order polynomial complexity and so it=E2=80= =99s > possible for a Lua program that executes a small number of bytecodes > to create a string that takes a vast amount of time to match on. > Again, this is also a problem for eBPF if you expose a similar > function, the solution is to not expose functions with large > data-dependent runtimes to untrusted script. >=20 > More generally, there are a lot of problems with interpreting or > JITing untrusted code in the kernel in *any* runtime. Speculative > execution makes it easy to use these as primitives to leak kernel > secrets, either via timing of the programs themselves, using the JIT > to generate gadgets, or by leaking data via cache priming. >=20 > Both eBPF and Lua have these problems. >=20 > The thing I would like to see for our current use of semi-trusted Lua > in the kernel (ZFS channel programs) is a way of exposing them (under > /dev/something) as file descriptors and modifying the ioctls that run > them to take a file descriptor argument. I would like to separate > the two operations: >=20 > - Load a channel program. > - Run a channel program. >=20 > In the post-Spectre world, the former remains a privileged operation. > Even though Linux pretends it isn=E2=80=99t, allowing arbitrary (even > arbitrary constrained) code to run in the kernel=E2=80=99s address space = is a > problem. Invoking such code; however, should follow the same rules > as everything else. A trusted entity should be able to load a pile > of Lua / eBPF / BPF64 / whatever programs into the kernel and then > set up permissions so that sandboxed programs (and jails) can use a > defined subset of them. >=20 > David >=20 This sounds a lot like IBM i / OS400 / System/360, or even Singularity from Microsoft, which uses a trusted JIT or AOT compiler to convert arbitrary bytecode to constrained machine code, so the machine code translator becomes the only trusted party, to accept or reject the arbitrary source (byte)code from the user. - Justin