On 11/30/19 2:37 AM, Eric Dumazet wrote:
On 11/29/19 2:29 PM, Daniel Borkmann wrote:
For the case where the interpreter is compiled out or when the prog is jited
it is completely unnecessary to set the BPF insn pages as read-only. In fact,
on frequent churn of BPF programs, it could lead to performance degradation of
the system over time since it would break the direct map down to 4k pages when
calling set_memory_ro() for the insn buffer on x86-64 / arm64 and there is no
reverse operation. Thus, avoid breaking up large pages for data maps, and only
limit this to the module range used by the JIT where it is necessary to set
the image read-only and executable.
Interesting... But why the non JIT case would need RO protection ?
It was done for interpreter around 5 years ago mainly due to concerns from security
folks that the BPF insn image could get corrupted (through some other bug in the
kernel) in post-verifier stage by an attacker and then there's nothing really that
would provide any sort of protection guarantees; pretty much the same reasons why
e.g. modules are set to read-only in the kernel.
Do you have any performance measures to share ?
No numbers, and I'm also not aware of any reports from users, but it was recently
brought to our attention from mm folks during discussion of a different set:
https://lore.kernel.org/lkml/1572171452-7958-2-git-send-email-rppt@xxxxxxxxxx/T/
Thanks,
Daniel
