From nobody Mon Oct 14 07:33:33 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 4XRprB3hxfz5ZM55; Mon, 14 Oct 2024 07:33:46 +0000 (UTC) (envelope-from theraven@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 4XRprB2nZZz4Vsk; Mon, 14 Oct 2024 07:33:46 +0000 (UTC) (envelope-from theraven@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1728891226; 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=iE2Bc2+JYMr/3dORZ1efguwqLVktYNwYS4KXYTtfwwM=; b=VF3ZJH8+9cwzDhZUbQeENfdhz8Xt/Izp/ysfooQXV03xvHipWxP5Pq5mtdZie0FQLZwGHM 7hOzUSk8TApb1GVzXMkFakidosRlhx9+EoQd2Qj+j1OxN1yH6anaGL73S/GF/fiOHjsFhh fjYpXtqaAyU5/UgxHg96bQqhgNQD3a3mSbbXGwtlL8yt/vl+kfJRzFQebju5AfWETszKIf s8z2KGknVfA9Z/ZuV4jjahyz+QainmK1iJo8e0/GmeYLmKgnITunoHysK9aWxGLCoK0Csf MEjzvJ85t4ToblNAXSAYe02JKbeXT+eZ37kS7M6cH5vLgs6WJ8c73Icb4RPTlg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1728891226; 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=iE2Bc2+JYMr/3dORZ1efguwqLVktYNwYS4KXYTtfwwM=; b=T7eHvqFdOj71cIk5ZhZIcKxHFQBB5ioG5hZAHiHATNVMo1MxYtNbvKR7Kfy/Mc+w0DNANg TKgSsmssrvV7XL38UxBqqjo4RFMmmO4BtfITC5AjHTq0nVS8AeiunX3PUd7jFZ6z4DB9Fl lSvlN7pVINu/RTXp3FjK7dnfVgV75mOEZMAgwX/SOFT+146rQ9qcto0GX86iTs8IR8MFuJ zfrSJLS2XHQUB+SkNVyvtlAFL76tecZpihSqymd2r/AooX/lDc1eXklJ+1cryryxntuyUj VczHWE0M6Lk0Z3OZWEm4xKcp/S0EGJfJoTBsInjNoAgKGVCwQEzkeNTq5JZWpQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1728891226; a=rsa-sha256; cv=none; b=Hkw8TL6rb1pfupmEF54I03Bxdquyc8+xCKH3OYd93rveNRXd48uOfnppnxl3zGO24dmctb Ig8yAupIFTslhKvlojqBYvmazbdVlYNV14n8TDuH5gPXmMogBlgfTM9FdTVXiiaceLd5+p zxrrFQidVvaz61CHu71q6YEv6XRfpHOJ/kuumXu3IAdYVgwYIpjYlnpckjDjvze/iv3iJp tafDz6q7ddHLUag1OtK/Xgf7hEws9z7/Z397VZIoRDuvBZGsaVQxLHGUjS0Kkh5T2HkdPW QY0t5EVfAkvKdmcFUYrRgilZ/2zqanhk6YrqvKbwl4NkCPqsIScNU3b2lGzULA== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (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) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XRprB2DRzz1Hwv; Mon, 14 Oct 2024 07:33:46 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtpclient.apple (host81-141-222-158.range81-141.btcentralplus.com [81.141.222.158]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 80E338F37; Mon, 14 Oct 2024 08:33:45 +0100 (BST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: David Chisnall 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 (1.0) Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative Date: Mon, 14 Oct 2024 08:33:33 +0100 Message-Id: <1FFE8A39-0061-4749-B9AD-65BE31CABAE0@freebsd.org> References: <20241014024912.B82FD289@slippy.cwsent.com> Cc: "Kevin P. Neal" , "Gavin D. Howard" , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org, freebsd-net@freebsd.org, tcpdump-workers@lists.tcpdump.org, tech-net@netbsd.org, Alexander Nasonov In-Reply-To: <20241014024912.B82FD289@slippy.cwsent.com> To: Cy Schubert X-Mailer: iPad Mail (21G93) > On 14 Oct 2024, at 03:49, Cy Schubert wrote: >=20 >> It >> can be solved, I think the DirectX LLVM backend ("DXIL") does this, but I= >> still suggest you not do this. NaCl and SPIR made this mistake first. WebAssembly and SPIR-V learned the le= sson. >> LLVM is huge. Really huge. A codebase that large has no business being in= >> the kernel. Many years ago, I wrote a proof of concept BPF to LLVM IR compiler. The idea= was that a trusted userspace component could do the BPF compilation and loa= d binary code into the kernel. BPF would still be BPF and so have the same g= uarantees, but compiling it would be faster (on average, each BPF bytecode w= as slightly more than one x86 instruction after LLVM optimisations had run).= LLVM was still in the TCB though, even in userspace. I didn=E2=80=99t perus= e it because LLVM is *not* safe in the presence of untrusted inputs. More generally, the LLVM IR model is similar to C. It allows arbitrary point= er casts and arbitrary pointer arithmetic. It is not a good starting point f= or anything that you want to analyse for security. LLVM analyses take advant= age of undefined behaviour. An in-bounds address calculation instruction is a= n assertion from the front end that the result will be in bounds. Optimisati= ons are free to rely on this, even when they can=E2=80=99t prove it, because= it is undefined behaviour to claim something is in bounds when it is not. T= he same is true of a lot of other properties on the IR. Many are not computa= ble to recover post facto, they rely on translation from a higher-level lang= uage that enforces the properties by construction. David