On 23.10.2020 12.02, Catalin Marinas wrote:
On Thu, Oct 22, 2020 at 01:02:18PM -0700, Kees Cook wrote:
Regardless, it makes sense to me to have the kernel load the executable
itself with BTI enabled by default. I prefer gaining Catalin's suggested
patch[2]. :)
[...]
[2] https://lore.kernel.org/linux-arm-kernel/20201022093104.GB1229@gaia/

I think I first heard the idea at Mark R ;).

It still needs glibc changes to avoid the mprotect(), or at least ignore
the error. Since this is an ABI change and we don't know which kernels
would have it backported, maybe better to still issue the mprotect() but
ignore the failure.

What about kernel adding an auxiliary vector as a flag to indicate that BTI is supported and recommended by the kernel? Then dynamic loader could use that to detect that a) the main executable is BTI protected and there's no need to mprotect() it and b) PROT_BTI flag should be added to all PROT_EXEC pages.

In absence of the vector, the dynamic loader might choose to skip doing PROT_BTI at all (since the main executable isn't protected anyway either, or maybe even the kernel is up-to-date but it knows that it's not recommended for some reason, or maybe the kernel is so ancient that it doesn't know about BTI). Optionally it could still read the flag from ELF later (for compatibility with old kernels) and then do the mprotect() dance, which may trip seccomp filters, possibly fatally.

-Topi

Reply via email to