From nobody Tue Sep 10 15:17:11 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 4X36kj54Gbz5W0jd; Tue, 10 Sep 2024 15:17:17 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X36kh6wg7z4h7w; Tue, 10 Sep 2024 15:17:16 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-5365b71a6bdso5150035e87.2; Tue, 10 Sep 2024 08:17:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725981434; x=1726586234; darn=freebsd.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=W+EtQAWIcFr+qyUilH/Xt2d7xpL9Fl6f8mgiQAu4olk=; b=O55e2XG+xisoVf3uMiBEdhWfYniaXzAQYrUJHVg1sXj+MGRDanOdQtICsuv2TplTUd 361DPWCVnIWoTon7NGA5ZFKuCwah9rllLz2PgBDZ5irWsyjMNvBGlV4zL1RSEG9AGc1K cqJEb2v3amcci6zXKiGeSsGF7J1tttOMVTCXGB7OTZrHsFKlNamq49nFO52z2aJoVCau qYS/8MbEzTkiVBWd6eN/zj5EMlRnU4OUZQ6wA/LcAIZ2MK3TGfFBx0dy7VSGo9RfDXnu 71K/kQN2Naz+TxI3d0kqtx2jK5+kHCZVZB9UmVSjSVft0Htg1CsizUjN1s2Pis5IiEDa c8ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725981434; x=1726586234; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=W+EtQAWIcFr+qyUilH/Xt2d7xpL9Fl6f8mgiQAu4olk=; b=nhnhVMjkVhbtgyGerv/WRmZ6ndHTbdBeB1YerOkPrdYsbUp+9pfggG+d5ebzXDupzX SNVNtyxo5DB6XjZ9iaHz441XZchTvtILLfzQqO0ibs3D6iY+Vky+2J7x0gLCqob7xWCA j0V0SwqY42VwSkwQKoTHv6EdCpq0415eqcv++FfBK5F3mUXwmZQBa4VrZU2JbrM9p/Hl pQt/z312SqP3iMMPpIGwj1axb1gYujizwFW2fUWxIAoLRhDXT7uxmoZoHicoHLZzl6tx 9IHWEe8vZl4LaUM8E3CNODNks45tenshhhkLuZeQrVIB4PiK/JyW5Y0MxxHooag5Atnt IsjQ== X-Forwarded-Encrypted: i=1; AJvYcCUBrZXLR5iL++2H5jTPRqk24AzFLTFq+nhBgOtGpW6la2Jo5125JwEVlVHTVydGUunpyTsumveEuwYKSL7ezUE=@freebsd.org, AJvYcCV/6pcIHgaoxKppqu7x19+k1dC7jaMNwXUoVjAyP6Rcwnj44SECl2i57W1dI1As7Q1IuvjU6a2DxYWdVEg=@freebsd.org X-Gm-Message-State: AOJu0YxorJ8tM1QPfCYVH3paHt3Gxxx7OdtWyIfkil/ZctV41tMyvebk B4eWRJ1FE0MGH4j+RKYUW1frAQgw0q8FWJu9Y/Vi+/eN8xnuRPOT X-Google-Smtp-Source: AGHT+IHB+HtNqR5Mhpl+gR9Q78EPAz5C5X6JRviKpNPloEM6ML1p7/WA+anUT0/yPZnqvpaJWeXDyw== X-Received: by 2002:a05:6512:2215:b0:534:5453:ecda with SMTP id 2adb3069b0e04-536587ae6c8mr9702590e87.23.1725981433978; Tue, 10 Sep 2024 08:17:13 -0700 (PDT) Received: from nuclight.lan ([37.204.254.214]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5365f86925asm1198726e87.31.2024.09.10.08.17.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Sep 2024 08:17:13 -0700 (PDT) Date: Tue, 10 Sep 2024 18:17:11 +0300 From: Vadim Goncharov To: "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: <20240910181711.5d324ac5@nuclight.lan> In-Reply-To: References: <20240910040544.125245ad@nuclight.lan> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; amd64-portbld-freebsd12.4) 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-Transfer-Encoding: 7bit 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:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4X36kh6wg7z4h7w On Tue, 10 Sep 2024 14:41:20 +0000 "Gavin D. Howard" wrote: > Hello, > > New user here, not a contributor. > > > Ensuring kernel stability? Just don't allow arbitrary pointers, > > like original 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 analyze for > > what purpose. You'll find these are needed for loops on packet > > contents. 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. Sure, but then look at practical usefulness: suppose you have stack of 32 frames (current limit of eBPF and BPF64). Then you can have only 31 iterations on a loop, loosing ability to call more functions from loop body. > 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. > * Either that, or someone builds an LLVM-to-bytecode > translator. Well, using LLVM were supposed for higher-level languages when bytecode is no longer experimental, utilizing full power of optimizer, but for direct using... let's see how they use it in Linux currently: 1) you write .c code, relatively low-level/restricted, with eBPF .h-s 2) clang turns .c into LLVM IR file (yes, this step is separate, may be things has changed since then, but at least it was so) 3) file with LLVM IR turned to eBPF bytecode in ELF file 4) ELF .o loaded by ip(8) or specialized loader into kernel 5) verifier checks it and most probably will return error to you :) 6) bytecode is JIT-compiled in kernel and then may be run Linux people are in mood "let's throw more man-months instead of thinking of better design", eBPF infrastructure consists of hundreds of thousandls lines of code, but seems that utilizing LLVM IR directly required too much resources even from them so was rejected. > * 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. So BPF64 took simplicity pass: while you have tutorials etc. it's still very hard to write (non-toy) code that passes verifier. I think a language where you do not need backward jumps but have usable constructs (so you just can't write bad code), even BAW, is a better way to go than try to train people to fight with unnecessary Cerber. > Please take my words with a full dose of salt; I'm not an expert on > this or on FreeBSD goals. BPF64 is not FreeBSD-only, you can see several non-FreeBSD mailing lists here. It can be cross-platform and independent enough to be implemented in e.g. network card or switch, for performance - having more registers allows to achieve better results then eBPF for same goal. -- WBR, @nuclight