[PATCH v1 2/2] arm64: Enable BTI for main executable as well as the interpreter

[Mark Brown]

On Thu, Jun 03, 2021 at 04:40:35PM +0100, Dave Martin wrote:

> Do we know how libcs will detect that they don't need to do the
> mprotect() calls?  Do we need a detection mechanism at all?

> Ignoring certain errors from mprotect() when ld.so is trying to set
> PROT_BTI on the main executable's code pages is probably a reasonable,
> backwards-compatible compromise here, but it seems a bit wasteful.

I think the theory was that they would just do the mprotect() calls and
ignore any errors as they currently do, or declare that they depend on a
new enough kernel version I guess (not an option for glibc but might be
for others which didn't do BTI yet).

> > flexibility userspace has to disable BTI but it is expected that for cases
> > where there are problems which require BTI to be disabled it is more likely
> > that it will need to be disabled on a system level.

> There's no flexibility impact unless MemoryDenyWriteExecute is in force,
> right?

Right, or some other mechanism that has the same effect.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210603/f7d01281/attachment.sig>