Hornet uses a similar signature verification scheme similar to that of kernel modules. A pkcs#7 signature is appended to the end of an executable file. During an invocation of bpf_prog_load, the signature is fetched from the current task’s executable file. That signature is used to verify the integrity of the bpf instructions and maps which where passed into the kernel. Additionally, Hornet implicitly trusts any programs which where loaded from inside kernel rather than userspace, which allows BPF_PRELOAD programs along with outputs for BPF_SYSCALL programs to run.
So this is to make kernel-level instructions from userspace (something that’s already happening) more secure.
The thread linked by the OP is Jarkko Sakkinen (kernel maintainer) seemingly saying “show your work, your patch is full of nonsense” in a patch submitted for review to the Linux kernel.
Edit: the OP has edited the link, it used to point to this comment in the mailing list chain.
The thread linked by the OP is Jarkko Sakkinen (kernel maintainer) seemingly saying “show your work, your patch is full of nonsense” in a patch submitted for review to the Linux kernel.
That’s not what he’s saying. He’s saying: ‘You’re using terms which aren’t that familiar to everyone. Could you explain them?’
Loading BPF code from user space is, I hope, only possible with root access to the system.
That would mean that an attacker needs root access to exploit BPF, but if an attacker has root access what stops him/her to do anything they want? At this time the system is lost anyway.
Ah yes, the “extended Berkeley Packet Filter”.
Wikipedia:
Phoronix:
So this is to make kernel-level instructions from userspace (something that’s already happening) more secure.
The thread linked by the OP is Jarkko Sakkinen (kernel maintainer) seemingly saying “show your work, your patch is full of nonsense” in a patch submitted for review to the Linux kernel.
Edit: the OP has edited the link, it used to point to this comment in the mailing list chain.
That’s not what he’s saying. He’s saying: ‘You’re using terms which aren’t that familiar to everyone. Could you explain them?’
Loading BPF code from user space is, I hope, only possible with root access to the system. That would mean that an attacker needs root access to exploit BPF, but if an attacker has root access what stops him/her to do anything they want? At this time the system is lost anyway.
Or am I missing anything?
If the executable binary has to be signed with a key, similar to the module signing key, Microsoft could sign their binaries
This, along with secureboot, would prevent the owner of the machine from running eBPF programs Microsoft doesn’t want you to run, even with root
Yeah, that’s why I am against Microsoft Keys on my systems
I fail to see the positive side of that…
Odds are because there isn’t one.
Abusers will always try to justify their abuse by saying their victims “don’t understand” why it’s “necessary.”
I wasn’t trying to give a positive side, I was just explaining why Microsoft wants the feature
Backdoor hidden in plain sight?