Date: Thu, 12 Sep 2024 12:04:35 +0100 From: David Chisnall <theraven@FreeBSD.org> To: Vadim Goncharov <vadimnuclight@gmail.com> Cc: Philip Paeps <philip@trouble.is>, freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org, freebsd-net@freebsd.org, tech-net@netbsd.org Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative Message-ID: <746547C3-DF15-435D-AECE-9B2D195703B5@FreeBSD.org> In-Reply-To: <20240912025717.455295f1@nuclight.lan> References: <20240911120518.1ba191b5@nuclight.lan> <E46A2E65-C529-4A74-984B-27E75CB77936@freebsd.org> <20240912025717.455295f1@nuclight.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <vadimnuclight@gmail.com> = 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 <html><head><meta http-equiv=3D"content-type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;">On 12 Sep = 2024, at 00:57, Vadim Goncharov <vadimnuclight@gmail.com> = wrote:<br><div><blockquote type=3D"cite"><br = class=3D"Apple-interchange-newline"><div><meta charset=3D"UTF-8"><span = style=3D"caret-color: rgb(0, 0, 0); font-family: SourceCodePro-Regular; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none; float: none; display: inline !important;">This is just not true. = See, for example, FreeBSD-SA-17:06.openssh for</span><br = style=3D"caret-color: rgb(0, 0, 0); font-family: SourceCodePro-Regular; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none;"><span style=3D"caret-color: rgb(0, 0, 0); font-family: = SourceCodePro-Regular; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline = !important;">vulnerability disabled by default, and workaround proposed = to return</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: = SourceCodePro-Regular; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;"><span style=3D"caret-color: rgb(0, 0, 0); = font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline !important;">to = default (disabled) state.</span><br style=3D"caret-color: rgb(0, 0, 0); = font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;"></div></blockquote><div><br></div><div>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.</div><br><blockquote = type=3D"cite"><div><span style=3D"caret-color: rgb(0, 0, 0); = font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline !important;">Stop. = Just stop, and re-read carefully. = </span></div></blockquote><div><br></div><div>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.</div><br><blockquote = type=3D"cite"><div><span style=3D"caret-color: rgb(0, 0, 0); = font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline !important;">You = (and perhaps Philip)</span><br style=3D"caret-color: rgb(0, 0, 0); = font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;"><span style=3D"caret-color: rgb(0, 0, 0); = font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline = !important;">confusing two things: BPF and eBPF (and BPF64 third), all = completely</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: = SourceCodePro-Regular; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;"><span style=3D"caret-color: rgb(0, 0, 0); = font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline = !important;">different = beasts.</span></div></blockquote><div><br></div><div>They are all = mechanisms for running semi-trusted / untrusted code in the = kernel.</div><br><blockquote type=3D"cite"><div><span = style=3D"caret-color: rgb(0, 0, 0); font-family: SourceCodePro-Regular; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none; float: none; display: inline !important;"> Last two letters in = this thread, I was talking about</span><br style=3D"caret-color: rgb(0, = 0, 0); font-family: SourceCodePro-Regular; font-size: 12px; font-style: = normal; font-variant-caps: normal; font-weight: 400; letter-spacing: = normal; text-align: start; text-indent: 0px; text-transform: none; = white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;"><span style=3D"caret-color: rgb(0, 0, 0); = font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline !important;">classic = BPF existing in *BSD for decades (on FreeBSD allowed to have</span><br = style=3D"caret-color: rgb(0, 0, 0); font-family: SourceCodePro-Regular; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none;"><span style=3D"caret-color: rgb(0, 0, 0); font-family: = SourceCodePro-Regular; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline = !important;">permissions on dev/bpf*). = </span></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote type=3D"cite"><div><span = style=3D"caret-color: rgb(0, 0, 0); font-family: SourceCodePro-Regular; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none; float: none; display: inline !important;">So you assert that THIS = classic BPF also</span><br style=3D"caret-color: rgb(0, 0, 0); = font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;"><span style=3D"caret-color: rgb(0, 0, 0); = font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline = !important;">vulnerable to aforementioned attacks, and thus SA must be = issued, just</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: = SourceCodePro-Regular; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;"><span style=3D"caret-color: rgb(0, 0, 0); = font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline !important;">like = that FreeBSD-SA-17:06.openssh, with a fix (at least preventing</span><br = style=3D"caret-color: rgb(0, 0, 0); font-family: SourceCodePro-Regular; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none;"><span style=3D"caret-color: rgb(0, 0, 0); font-family: = SourceCodePro-Regular; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline = !important;">changing default permissions) of hole existing for = *decades*.</span></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><br><blockquote type=3D"cite"><div><span = style=3D"caret-color: rgb(0, 0, 0); font-family: SourceCodePro-Regular; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none; float: none; display: inline !important;"> This is</span><br = style=3D"caret-color: rgb(0, 0, 0); font-family: SourceCodePro-Regular; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none;"><span style=3D"caret-color: rgb(0, 0, 0); font-family: = SourceCodePro-Regular; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline !important;">too = strong assertion to be accepted without proofs, and as I can = deduce</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: = SourceCodePro-Regular; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;"><span style=3D"caret-color: rgb(0, 0, 0); = font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline !important;">from = your other words and readings about Spectre (see below), this</span><br = style=3D"caret-color: rgb(0, 0, 0); font-family: SourceCodePro-Regular; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none;"><span style=3D"caret-color: rgb(0, 0, 0); font-family: = SourceCodePro-Regular; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline = !important;">statement is not true (classic /dev/bpf is not = vulnerable).</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: = SourceCodePro-Regular; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;"></div></blockquote><div><br style=3D"caret-color: = rgb(0, 0, 0); font-family: SourceCodePro-Regular; font-size: 12px; = font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none;"></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>David</div><div><br></div><div><br></div>= <div><br></div></div><br></body></html>= --Apple-Mail=_10FE2401-9F6E-4915-9D75-86D8B0F37D7C--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?746547C3-DF15-435D-AECE-9B2D195703B5>