On Thu, Jul 18, 2024 at 8:55 AM Greg KH <greg@xxxxxxxxx> wrote:
>
> On Mon, Jul 01, 2024 at 11:46:59AM +0000, Puranjay Mohan wrote:
> > From: Russell King <russell.king@xxxxxxxxxx>
> >
> > [ Upstream commit b89ddf4cca43f1269093942cf5c4e457fd45c335 ]
> >
> > Commit 91fc957c9b1d ("arm64/bpf: don't allocate BPF JIT programs in module
> > memory") restricts BPF JIT program allocation to a 128MB region to ensure
> > BPF programs are still in branching range of each other. However this
> > restriction should not apply to the aarch64 JIT, since BPF_JMP | BPF_CALL
> > are implemented as a 64-bit move into a register and then a BLR instruction -
> > which has the effect of being able to call anything without proximity
> > limitation.
> >
> > The practical reason to relax this restriction on JIT memory is that 128MB of
> > JIT memory can be quickly exhausted, especially where PAGE_SIZE is 64KB - one
> > page is needed per program. In cases where seccomp filters are applied to
> > multiple VMs on VM launch - such filters are classic BPF but converted to
> > BPF - this can severely limit the number of VMs that can be launched. In a
> > world where we support BPF JIT always on, turning off the JIT isn't always an
> > option either.
> >
> > Fixes: 91fc957c9b1d ("arm64/bpf: don't allocate BPF JIT programs in module memory")
> > Suggested-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
> > Signed-off-by: Russell King <russell.king@xxxxxxxxxx>
> > Signed-off-by: Daniel Borkmann <daniel@xxxxxxxxxxxxx>
> > Tested-by: Alan Maguire <alan.maguire@xxxxxxxxxx>
> > Link: https://lore.kernel.org/bpf/1636131046-5982-2-git-send-email-alan.maguire@xxxxxxxxxx
> > [Replace usage of in_bpf_jit() with is_bpf_text_address()]
> > Signed-off-by: Puranjay Mohan <pjy@xxxxxxxxxx>
> > ---
> > arch/arm64/include/asm/extable.h | 9 ---------
> > arch/arm64/include/asm/memory.h | 5 +----
> > arch/arm64/kernel/traps.c | 2 +-
> > arch/arm64/mm/extable.c | 3 ++-
> > arch/arm64/mm/ptdump.c | 2 --
> > arch/arm64/net/bpf_jit_comp.c | 7 ++-----
> > 6 files changed, 6 insertions(+), 22 deletions(-)
> >
>
> This is reported to cause problems:
> https://lore.kernel.org/r/CA+G9fYtfAbfcQ9J9Hzq-e6yoBVG3t_iHZ=bS2eJbO_aiOcquXQ@xxxxxxxxxxxxxx
> so I will drop it now.
I will try to debug this!
> How did you test this?
I tested this on an AWS Graviton based EC2 instance by loading 16000
BPF programs.
> And if you really need this feature, why not move to a more modern
> kernel version?
> thanks,
>
> greg k-h
Thanks,
Puranjay
