Messages in this thread | | | Date | Fri, 23 Oct 2020 07:13:17 +0100 | From | Szabolcs Nagy <> | Subject | Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures |
| |
The 10/22/2020 10:31, Catalin Marinas wrote: > IIUC, the problem is with the main executable which is mapped by the > kernel without PROT_BTI. The dynamic loader wants to set PROT_BTI but > does not have the original file descriptor to be able to remap. Its only > choice is mprotect() and this fails because of the MDWX policy. > > Not sure whether the kernel has the right information but could it map > the main executable with PROT_BTI if the corresponding PT_GNU_PROPERTY > is found? The current ABI states it only sets PROT_BTI for the > interpreter who'd be responsible for setting the PROT_BTI on the main > executable. I can't tell whether it would break anything but it's worth > a try:
i think it would work, but now i can't easily tell from the libc if i have to do the mprotect on the main exe or not.
i guess i can just always mprotect and ignore the failure?
> > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c > index 4784011cecac..0a08fb9133e8 100644 > --- a/arch/arm64/kernel/process.c > +++ b/arch/arm64/kernel/process.c > @@ -730,14 +730,6 @@ asmlinkage void __sched arm64_preempt_schedule_irq(void) > int arch_elf_adjust_prot(int prot, const struct arch_elf_state *state, > bool has_interp, bool is_interp) > { > - /* > - * For dynamically linked executables the interpreter is > - * responsible for setting PROT_BTI on everything except > - * itself. > - */ > - if (is_interp != has_interp) > - return prot; > - > if (!(state->flags & ARM64_ELF_BTI)) > return prot; > > > -- > Catalin
--
| |