Note that BPF doesn't attempt to provide much of a security barrier.
> This access control mechanism does not in itself protect against malicious or erroneous processes attempting to divert packets; it only works when processes play by the rules. In the research environment for which the packet filter was developed, this has not been a problem, especially since there are many other ways to eavesdrop on an Ethernet.
And even on modern systems, you need to be root to install a packet filter, which is typically also sufficient privilege to simply open /dev/mem and read kernel memory directly. (Or you did, then people started using bpf for everything, but that came many years after the 386 and 486.)
I don't think BPF is a good example of running untrusted code, at least not the early versions, since it wasn't untrusted.
Right, I would contend that the threat model addressed by BPF is preventing trusted but buggy code from taking down the kernel, not protecting against malicious code.
Regardless of whether it's 1987 or 1993 that you want to date the beginning of SFI to, it's certainly the case that SFI is explicitly designed to protect against malicious code. CPU designers have had a long time to deal with that, and you didn't see them telling people not to do it back then.
> This access control mechanism does not in itself protect against malicious or erroneous processes attempting to divert packets; it only works when processes play by the rules. In the research environment for which the packet filter was developed, this has not been a problem, especially since there are many other ways to eavesdrop on an Ethernet.
And even on modern systems, you need to be root to install a packet filter, which is typically also sufficient privilege to simply open /dev/mem and read kernel memory directly. (Or you did, then people started using bpf for everything, but that came many years after the 386 and 486.)
I don't think BPF is a good example of running untrusted code, at least not the early versions, since it wasn't untrusted.