From nobody Thu Sep 12 11:04:35 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 4X4F2S2Z0Jz5WBpH; Thu, 12 Sep 2024 11:04:48 +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 4X4F2S22NSz4vpr; Thu, 12 Sep 2024 11:04:48 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1726139088; 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: in-reply-to:in-reply-to:references:references; bh=5XCP+OtTCjv0BrnUPkhgNamjxRyHSjEizsK/4AyPSBw=; b=ULGygp69dhp5iepNCNIxJwvU8JhuN2XttxgIcksnENWn/EkpWlZMBN1/bsv2rLJTwHnLPf 5MImRTxEq5If68X23Td4Ou+Tft+r3y4Xx28CqvaZmYQQ9FMGDRKMjOdDUlKflh1PAobTle cLViEG004vf50NwrD1E7BA5cIEE9z5YDp9Ht/y9b+fjc1RC2Ncwi9rcRR6toD3wkJZarwL 3grzszg0kMJs2HNJycX5ftumlBwT+KeTRlfdOgYaC0lhp/b3/X86iETKGnSuKzFO9oJvxg IBgHq9vkJ3IHOROxGGQQmhe6rKU3Yv9pDuZ/N4r5FTT9O32j6/XMYR6uujvqQA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1726139088; a=rsa-sha256; cv=none; b=wxPxwDj8dWbkf2i7is2g5+KNMe+VnjkUC1Zuy28Y8p1vZH+eUoM43beUdzU9wAGTavdA3a LaSn0+8q9rYBoHa/6uoFfZJyZW3B0f0Wh7fr1/hXWuAUpM5+YyXlE8Z8NqNS8Xaekp/9LS An2P7ZA2UUnhcZCS0sAHLVmcLuYwcuutD3/Xa1p3ynRBMvYoBntkjqWmOESESk/sKhRjLy LMZYeOeGo//hqCcldzRfTYZBF+O3bll+mpfhVlIRY8s+u/9Jm6l8p6jczAhgXPOA3P4W5k Cz5ykBolBFp6rE/rZuXKZ+4YvkjcuTmdOuUjwcKB/Y34W2hxhs0f4GRN7FKmkA== 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=1726139088; 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: in-reply-to:in-reply-to:references:references; bh=5XCP+OtTCjv0BrnUPkhgNamjxRyHSjEizsK/4AyPSBw=; b=Q5F34EXluziTC0xEWXA/U7vv5rQteg2SuSGd/bAu9eC0RWEQImbmQIvw8YSk3YMA7bV8uG 4/1W3Rqxjj4+7edt26NTqWFJlThUXjjNL+Bi9hBp1gJvQIdOyP23F9x9B0AOxHp3gusPkh iZPdXa+dIvaoOJyHF0PTCvvTbEE2cwsQ0Fw37Lp5ZVi40my7cvEIYrnaLm1IVHv4nfM3gk ULPUhz9GQBFaMxn+fSWGdzbIagta91PkI3NRZoiZF0Vkq/wODgbj3IOrc6uS7nc0hY915P Mh7LF7d/YeKlYvsxlC2woNOIKEiqqUn03nHgNnC6vjvUBytj0GSi7ebwg/uo1g== 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 4X4F2S1RrKzPkW; Thu, 12 Sep 2024 11:04:48 +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 E3E7A6603; Thu, 12 Sep 2024 12:04:46 +0100 (BST) From: David Chisnall Message-Id: <746547C3-DF15-435D-AECE-9B2D195703B5@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_10FE2401-9F6E-4915-9D75-86D8B0F37D7C" 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 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative Date: Thu, 12 Sep 2024 12:04:35 +0100 In-Reply-To: <20240912025717.455295f1@nuclight.lan> Cc: Philip Paeps , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org, freebsd-net@freebsd.org, tech-net@netbsd.org To: Vadim Goncharov References: <20240911120518.1ba191b5@nuclight.lan> <20240912025717.455295f1@nuclight.lan> X-Mailer: Apple Mail (2.3776.700.51) --Apple-Mail=_10FE2401-9F6E-4915-9D75-86D8B0F37D7C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 12 Sep 2024, at 00:57, Vadim Goncharov = wrote: >=20 > This is just not true. See, for example, FreeBSD-SA-17:06.openssh for > vulnerability disabled by default, and workaround proposed to return > to default (disabled) state. No, this was changing from one supported expected-secure setting to = another. If you make a device directly usable by non-root users, you = are expected to understand the security implications. > Stop. Just stop, and re-read carefully. I have read carefully. I am not sure at this point whether you are = intentionally failing to engage in good faith or if you simply do not = understand the security landscape that you are operating in and have no = interest in learning. Either way, it is not productive to keep having = this conversation so this will be my last comment in this thread. > You (and perhaps Philip) > confusing two things: BPF and eBPF (and BPF64 third), all completely > different beasts. They are all mechanisms for running semi-trusted / untrusted code in the = kernel. > Last two letters in this thread, I was talking about > classic BPF existing in *BSD for decades (on FreeBSD allowed to have > permissions on dev/bpf*). FreeBSD allows you to change the permissions on anything in /dev/. It = is up to you to understand the security implications of doing this. = Allowing non-root access to /dev/bpf has security implications. I do it = for my user on a couple of single-user FreeBSD dev boxes, because I also = have root on these systems and so anything WireShark can do on my = behalf, I can also do via su. There is no security issue because my = threat model *for this system* is such that I can accept a weaker = posture than the default. There are legitimate reasons for broadening = the permissions on these systems. > So you assert that THIS classic BPF also > vulnerable to aforementioned attacks, and thus SA must be issued, just > like that FreeBSD-SA-17:06.openssh, with a fix (at least preventing > changing default permissions) of hole existing for *decades*. No, for the same reason that there=E2=80=99s no security advisory if you = `chmod +r /dev/mem`. There=E2=80=99s a reason that both /dev/mem and = /dev/bpf are restricted to root by default. Anyone who relaxes these = permissions must understand what they=E2=80=99re doing and have a threat = model that can justify why it=E2=80=99s acceptable. By analogy with FreeBSD-SA-17:06.openssh: this SA applied where password = login was enabled. Enabling password authentication weakens the = security of OpenSSH and so is not done by default, but that was not the = problem that merited the SA. The SA was issued because it had the = additional effect of allowing remote attackers to mount a denial of = service attack. We would not issue an OpenSSH SA saying =E2=80=98enabling= password authentication weakens security because people can log in with = passwords, which are less secure than SSH keys=E2=80=99. The = expectation is that anyone changing this setting knows what they=E2=80=99r= e doing. If it is not a problem for their use case, they can do it. = Precisely the same logic applies to allowing non-root access to /dev/bpf = or /dev/mem. > This is > too strong assertion to be accepted without proofs, and as I can = deduce > from your other words and readings about Spectre (see below), this > statement is not true (classic /dev/bpf is not vulnerable). I have not built a PoC, but I would fully expect that it=E2=80=99s = possible to build an attack that first primes the cache and trains the = branch predictor and then runs a crafted BPF program that has an = out-of-bounds read (which executes only in speculation) to leak kernel = memory (including contents of the direct map, so anything owned by = another process on the same system), and then inspects the contents of = the cache to see the value that was observed in speculation. All of the = necessary primitives are there. If you are designing a system that expects non-root users to be able to = run code in the kernel, the onus is on you to explain why it is safe. = The default assumption must be that it is unsafe. David --Apple-Mail=_10FE2401-9F6E-4915-9D75-86D8B0F37D7C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On 12 Sep = 2024, at 00:57, Vadim Goncharov <vadimnuclight@gmail.com> = wrote:

This is just not true. = See, for example, FreeBSD-SA-17:06.openssh for
vulnerability disabled by default, and workaround proposed = to return
to = default (disabled) state.

No, this = was changing from one supported expected-secure setting to another. =  If you make a device directly usable by non-root users, you are = expected to understand the security implications.

Stop. = Just stop, and re-read carefully. =

I have read carefully. =  I am not sure at this point whether you are intentionally failing = to engage in good faith or if you simply do not understand the security = landscape that you are operating in and have no interest in learning. =  Either way, it is not productive to keep having this conversation = so this will be my last comment in this thread.

You = (and perhaps Philip)
confusing two things: BPF and eBPF (and BPF64 third), all = completely
different = beasts.

They are all = mechanisms for running semi-trusted / untrusted code in the = kernel.

Last two letters in = this thread, I was talking about
classic = BPF existing in *BSD for decades (on FreeBSD allowed to have
permissions on dev/bpf*). =

FreeBSD allows you to = change the permissions on anything in /dev/.  It is up to you to = understand the security implications of doing this.  Allowing = non-root access to /dev/bpf has security implications.  I do it for = my user on a couple of single-user FreeBSD dev boxes, because I also = have root on these systems and so anything WireShark can do on my = behalf, I can also do via su.  There is no security issue because = my threat model *for this system* is such that I can accept a weaker = posture than the default.  There are legitimate reasons for = broadening the permissions on these = systems.

So you assert that THIS = classic BPF also
vulnerable to aforementioned attacks, and thus SA must be = issued, just
like = that FreeBSD-SA-17:06.openssh, with a fix (at least preventing
changing default permissions) of hole existing for = *decades*.

No, for the same = reason that there=E2=80=99s no security advisory if you `chmod +r = /dev/mem`.  There=E2=80=99s a reason that both /dev/mem and = /dev/bpf are restricted to root by default.  Anyone who relaxes = these permissions must understand what they=E2=80=99re doing and have a = threat model that can justify why it=E2=80=99s = acceptable.

By analogy with = FreeBSD-SA-17:06.openssh: this SA applied where password login was = enabled.  Enabling password authentication weakens the security of = OpenSSH and so is not done by default, but that was not the problem that = merited the SA.  The SA was issued because it had the additional = effect of allowing remote attackers to mount a denial of service attack. =  We would not issue an OpenSSH SA saying =E2=80=98enabling password = authentication weakens security because people can log in with = passwords, which are less secure than SSH keys=E2=80=99.  The = expectation is that anyone changing this setting knows what they=E2=80=99r= e doing.  If it is not a problem for their use case, they can do = it.  Precisely the same logic applies to allowing non-root access = to /dev/bpf or /dev/mem.

This is
too = strong assertion to be accepted without proofs, and as I can = deduce
from = your other words and readings about Spectre (see below), this
statement is not true (classic /dev/bpf is not = vulnerable).

I = have not built a PoC, but I would fully expect that it=E2=80=99s = possible to build an attack that first primes the cache and trains the = branch predictor and then runs a crafted BPF program that has an = out-of-bounds read (which executes only in speculation) to leak kernel = memory (including contents of the direct map, so anything owned by = another process on the same system), and then inspects the contents of = the cache to see the value that was observed in speculation.  All = of the necessary primitives are there.

If you = are designing a system that expects non-root users to be able to run = code in the kernel, the onus is on you to explain why it is safe. =  The default assumption must be that it is = unsafe.

David


=


= --Apple-Mail=_10FE2401-9F6E-4915-9D75-86D8B0F37D7C--