Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative

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’s no security advisory if you `chmod +r /dev/mem`. There’s a reason that both /dev/mem and /dev/bpf are restricted to root by default. Anyone who relaxes these permissions must understand what they’re doing and have a threat model that can justify why it’s 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 ‘enabling password authentication weakens security because people can log in with passwords, which are less secure than SSH keys’. The expectation is that anyone changing this setting knows what they’re 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’s 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