| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 26 Jan 2022 15:35:01 +0000 (GMT)
From: Alan Maguire <alan.maguire@...cle.com>
To: Naresh Kamboju <naresh.kamboju@...aro.org>
cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Daniel Borkmann <daniel@...earbox.net>,
linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
akpm@...ux-foundation.org, linux@...ck-us.net, shuah@...nel.org,
patches@...nelci.org, lkft-triage@...ts.linaro.org,
Daniel Díaz <daniel.diaz@...aro.org>,
pavel@...x.de, jonathanh@...dia.com, f.fainelli@...il.com,
sudipm.mukherjee@...il.com, stable@...r.kernel.org,
Russell King <russell.king@...cle.com>,
Alan Maguire <alan.maguire@...cle.com>
Subject: Re: [PATCH 5.15 000/846] 5.15.17-rc1 review
On Tue, 25 Jan 2022, Naresh Kamboju wrote:
> On Tue, 25 Jan 2022 at 09:09, Daniel Díaz <daniel.diaz@...aro.org> wrote:
> >
> > Hello!
> >
> > On 1/24/22 16:50, Daniel Díaz wrote:
> > > Hello!
> > >
> > > On 1/24/22 12:31, Greg Kroah-Hartman wrote:
> > >> This is the start of the stable review cycle for the 5.15.17 release.
> > >> There are 846 patches in this series, all will be posted as a response
> > >> to this one. If anyone has any issues with these being applied, please
> > >> let me know.
> > >>
> > >> Responses should be made by Wed, 26 Jan 2022 18:39:11 +0000.
> > >> Anything received after that time might be too late.
> > >>
> > >> The whole patch series can be found in one patch at:
> > >> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.17-rc1.gz
> > >> or in the git tree and branch at:
> > >> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> > >> and the diffstat can be found below.
> > >>
> > >> thanks,
> > >>
> > >> greg k-h
> > >
>
> Regressions detected on arm, arm64, i386, x86 on 5.15 and 5.10
>
> > >
> > > This is one from arm64:
> > > /builds/linux/arch/arm64/mm/extable.c: In function 'fixup_exception':
> > > /builds/linux/arch/arm64/mm/extable.c:17:13: error: implicit declaration of function 'in_bpf_jit' [-Werror=implicit-function-declaration]
> > > 17 | if (in_bpf_jit(regs))
> > > | ^~~~~~~~~~
> > > cc1: some warnings being treated as errors
> > > make[3]: *** [/builds/linux/scripts/Makefile.build:277: arch/arm64/mm/extable.o] Error 1
> >
> > Bisection here pointed to "arm64/bpf: Remove 128MB limit for BPF JIT programs". Reverting made the build succeed.
>
> arm64/bpf: Remove 128MB limit for BPF JIT programs
> commit b89ddf4cca43f1269093942cf5c4e457fd45c335 upstream.
>
> Reported-by: Linux Kernel Functional Testing <lkft@...aro.org>
>
Thanks for the report!
This one needs slightly different handling on 5.15. Russell had a 5.15
patch for this (where BPF exception handling was still handled separately)
and I've included it below. I verified it applies cleanly to the
linux-5.15.y branch and builds. I'd suggest either skipping backport of
this fix to stable completely, or just applying the below to 5.15 and
skipping further backports.
Thanks!
>From dfe0e5d5c7101dd848822a7be8d0e63fa137919f Mon Sep 17 00:00:00 2001
From: Russell King <russell.king@...cle.com>
Date: Fri, 29 Oct 2021 15:37:01 +0100
Subject: [PATCH] arm64/bpf: remove 128MB limit for BPF JIT programs
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. Removing the contiguous JIT
region requires explicitly searching the bpf exception tables first
in fixup_exception(), since they are formatted differently from
the rest of the exception tables. Previously we used the fact that
the JIT memory was contiguous to identify the fact that the context
for the exception (the program counter) is a BPF program.
The approach used differs slightly from upstream since in 5.16 the
format of the exception tables was reorganized to accommodate BPF;
in upstream no explicit BPF exception handling was required.
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@...aro.org>
Signed-off-by: Russell King <russell.king@...cle.com>
Tested-by: Alan Maguire <alan.maguire@...cle.com>
Reviewed-by: Tom Saeger <tom.saeger@...cle.com>
---
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 | 13 +++++++++----
arch/arm64/mm/ptdump.c | 2 --
arch/arm64/net/bpf_jit_comp.c | 7 ++-----
6 files changed, 13 insertions(+), 25 deletions(-)
diff --git a/arch/arm64/include/asm/extable.h b/arch/arm64/include/asm/extable.h
index b15eb4a..840a35e 100644
--- a/arch/arm64/include/asm/extable.h
+++ b/arch/arm64/include/asm/extable.h
@@ -22,15 +22,6 @@ struct exception_table_entry
#define ARCH_HAS_RELATIVE_EXTABLE
-static inline bool in_bpf_jit(struct pt_regs *regs)
-{
- if (!IS_ENABLED(CONFIG_BPF_JIT))
- return false;
-
- return regs->pc >= BPF_JIT_REGION_START &&
- regs->pc < BPF_JIT_REGION_END;
-}
-
#ifdef CONFIG_BPF_JIT
int arm64_bpf_fixup_exception(const struct exception_table_entry *ex,
struct pt_regs *regs);
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index f1745a8..0588632 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -44,11 +44,8 @@
#define _PAGE_OFFSET(va) (-(UL(1) << (va)))
#define PAGE_OFFSET (_PAGE_OFFSET(VA_BITS))
#define KIMAGE_VADDR (MODULES_END)
-#define BPF_JIT_REGION_START (_PAGE_END(VA_BITS_MIN))
-#define BPF_JIT_REGION_SIZE (SZ_128M)
-#define BPF_JIT_REGION_END (BPF_JIT_REGION_START + BPF_JIT_REGION_SIZE)
#define MODULES_END (MODULES_VADDR + MODULES_VSIZE)
-#define MODULES_VADDR (BPF_JIT_REGION_END)
+#define MODULES_VADDR (_PAGE_END(VA_BITS_MIN))
#define MODULES_VSIZE (SZ_128M)
#define VMEMMAP_START (-(UL(1) << (VA_BITS - VMEMMAP_SHIFT)))
#define VMEMMAP_END (VMEMMAP_START + VMEMMAP_SIZE)
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index b03e383..fe0cd05 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -988,7 +988,7 @@ static int bug_handler(struct pt_regs *regs, unsigned int esr)
static int reserved_fault_handler(struct pt_regs *regs, unsigned int esr)
{
pr_err("%s generated an invalid instruction at %pS!\n",
- in_bpf_jit(regs) ? "BPF JIT" : "Kernel text patching",
+ "Kernel text patching",
(void *)instruction_pointer(regs));
/* We cannot handle this */
diff --git a/arch/arm64/mm/extable.c b/arch/arm64/mm/extable.c
index aa00601..60a8b6a 100644
--- a/arch/arm64/mm/extable.c
+++ b/arch/arm64/mm/extable.c
@@ -9,14 +9,19 @@
int fixup_exception(struct pt_regs *regs)
{
const struct exception_table_entry *fixup;
+ unsigned long addr;
- fixup = search_exception_tables(instruction_pointer(regs));
- if (!fixup)
- return 0;
+ addr = instruction_pointer(regs);
- if (in_bpf_jit(regs))
+ /* Search the BPF tables first, these are formatted differently */
+ fixup = search_bpf_extables(addr);
+ if (fixup)
return arm64_bpf_fixup_exception(fixup, regs);
+ fixup = search_exception_tables(addr);
+ if (!fixup)
+ return 0;
+
regs->pc = (unsigned long)&fixup->fixup + fixup->fixup;
return 1;
}
diff --git a/arch/arm64/mm/ptdump.c b/arch/arm64/mm/ptdump.c
index 1c40353..9bc4066 100644
--- a/arch/arm64/mm/ptdump.c
+++ b/arch/arm64/mm/ptdump.c
@@ -41,8 +41,6 @@ enum address_markers_idx {
{ 0 /* KASAN_SHADOW_START */, "Kasan shadow start" },
{ KASAN_SHADOW_END, "Kasan shadow end" },
#endif
- { BPF_JIT_REGION_START, "BPF start" },
- { BPF_JIT_REGION_END, "BPF end" },
{ MODULES_VADDR, "Modules start" },
{ MODULES_END, "Modules end" },
{ VMALLOC_START, "vmalloc() area" },
diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
index 803e777..465c44d 100644
--- a/arch/arm64/net/bpf_jit_comp.c
+++ b/arch/arm64/net/bpf_jit_comp.c
@@ -1138,15 +1138,12 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
u64 bpf_jit_alloc_exec_limit(void)
{
- return BPF_JIT_REGION_SIZE;
+ return VMALLOC_END - VMALLOC_START;
}
void *bpf_jit_alloc_exec(unsigned long size)
{
- return __vmalloc_node_range(size, PAGE_SIZE, BPF_JIT_REGION_START,
- BPF_JIT_REGION_END, GFP_KERNEL,
- PAGE_KERNEL, 0, NUMA_NO_NODE,
- __builtin_return_address(0));
+ return vmalloc(size);
}
void bpf_jit_free_exec(void *addr)
--
1.8.3.1
Powered by blists - more mailing lists