From nobody Wed Sep 11 11:21:09 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 4X3dS230wdz5WS1f; Wed, 11 Sep 2024 11:21:22 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4X3dS20pX2z4ZLd; Wed, 11 Sep 2024 11:21:22 +0000 (UTC) (envelope-from theraven@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1726053682; 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=f/2x/6NihxJiRrA1BaJGxpPygChNh4vd66EqRwfJEzQ=; b=maL8AuBoi5mVYQcLONv0iPiXg1fht+yMMOqm+CvjlIZ2TPrHMi9ZGyCYl5/f41yk6lW7Ay 4mjJu9HugSIlQ1+4tOkAibwKGMlrQ+aidcxmwVTsF1FZypo8zwcL2E5WGyEJT9GSQNfEvC ni0nvX7vJ5/yCuP12pxQMzj0+ALztRT4/cOkyoyCwY1/DNddFKiB3hTQaNYh2VD2IBCobf iKEHH1G7R4z+CIklTRRDHpXu45QqIFDseS8HhawIAdMxu2GqQXiMntMKiSKkBNkFjdogjD x+9oJ9iH+tQk1UKkcUiSY655Jbz5QchC2Zi66/Gqzt1txr3BGFNIpyE5FEjePw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1726053682; a=rsa-sha256; cv=none; b=nNimEszrCpoKTZ6eJJWhwAeIkHo2A24DEDAvdgJiivd1FIqwZNiub/Z33EjNyXsaSfcuzE dWVBYhhJWEX9/1AHuHv1SaKHBABu083XiZ01F0xJeAvjCALDdUXxhft3lGGr31/gTvucwk wDQPhpMr6wDBhw0cmw2w7T9f/Finaagu948QHlNKzRuFyn5TNGTtknKMcXhHG0UkI9gPMr VjgPnE6pvjG++rumuCEv61882Bjp0slSS3X3lWOuKkRSs0dh7laeX/i1FK+Gl9SmUbunDf YbgQ3NhMijzjqnw4CDXWmRs9TPiZU+7bZ5tkgal32K4YyI4ITRIdAqvaGnaPbw== 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=1726053682; 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=f/2x/6NihxJiRrA1BaJGxpPygChNh4vd66EqRwfJEzQ=; b=Jx69LwcELMGUEZggBBlBAssiSMYuDvjr1egy2h9mJd5tLnEClD0COIoplTIy+c5um90GK2 LgvMFdJAlTs7hEWr+K51Cv3bcv1yeYOvGe6sqQJH+1iFjLKSmCzF3DAGDcX2v8C7GbHkfO oJotKy9VmdeIT0K5hUUaKSom344zvg7gtnUcg8P9Sacu1gS9+9dS+K8Fvd9I8px6LO/OXi vGtbjK5016UmhsxxHEoPPJeGUdRF4TrLgmAUNtSUqedLuY7/wwZneASy9wRiAqIL8Nd6Pp DdXKeIWcov6be5miBqLrA7901hcnqcWWPFGMoppQwFB1cdx3Jm3wVHYSFWS2Gw== 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 4X3dS20FYrz18Zn; Wed, 11 Sep 2024 11:21:21 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id F245D65DC; Wed, 11 Sep 2024 12:21:20 +0100 (BST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: David Chisnall 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 (1.0) Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative Date: Wed, 11 Sep 2024 12:21:09 +0100 Message-Id: References: <20240911120518.1ba191b5@nuclight.lan> Cc: Philip Paeps , Poul-Henning Kamp , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org, freebsd-net@freebsd.org, tech-net@netbsd.org In-Reply-To: <20240911120518.1ba191b5@nuclight.lan> To: Vadim Goncharov X-Mailer: iPad Mail (21G93) On 11 Sep 2024, at 10:06, Vadim Goncharov wrote: >=20 > But then a possibility to give this to non-root is. And many things are > considered vulnerabilitites even if they are only available to root - > for example, when root can be tricked into running malicious code etc. > (unconscious) actions without direct intention. When the root user intentionality changes some thin from a secure default to= an insecure setting, it is not a security vulnerability in the system that s= hipped the safe defaults.=20 > Equivalency of classic BPF to writable /dev/mem is too loud and > controversial statement. Demonstrate how it can be done on stock > FreeBSD 13 with /dev/bpf available to attacker (e.g. `sudo tcpdump` > allowed). Two things to unpick here. First: Demanding a proof of concept before you accept that something is a vulnerabi= lity is how you build insecure systems. Ask the Matrix team how well that at= titude has worked for them in the last few weeks. You build secure systems b= y defining a threat model and then evaluating primitives against that threat= model, not by throwing together a bunch of primitives and saying =E2=80=98w= ell, *I* can=E2=80=99t assemble them into an exploit and so no one can=E2=80= =99. Second, there are documented attacks on eBPF that give the equivalent of *re= ad* access to /dev/mem. This is why BPF is restricted to root. We have a thr= eat model. The threat model says that we do not need to ensure that BPF cann= ot leak kernel data indirectly because only the user who has the ability to l= eak kernel data directly can use it and this user has a simpler way of achie= ving the same result. If you allow non-root users to run code (native or aga= inst any virtual machine) then you are changing the threat model. You *must*= prevent users from leaking kernel data that they could not leak via existin= g mechanisms. The two most common attacks using eBPF are generally in the following two ca= tegories: - Use eBPF to mount a speculative execution attack on the kernel. Please re= ad up on what these can do. No one should be building a thing that runs code= in the kernel without understanding speculative, cache, and timing side cha= nnels. - Use eBPF to build a set of gadgets that you can then use to go from one m= emory-safety bug in the kernel to arbitrary-code execution. This is the threat landscape in which something in the same space as eBPF mu= st exist. A proposed design should *start* with an explanation of how it mit= igates both of these categories of attack. David