[PATCH v4 07/12] aarch64: enable BTI at runtime

[H.J. Lu]

On Fri, Jun 12, 2020 at 6:34 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>
> From: Sudakshina Das <sudi.das@arm.com>
>
> Binaries can opt-in to using BTI via an ELF object file marking.
> The dynamic linker has to then mprotect the executable segments
> with PROT_BTI. In case of static linked executables or in case
> of the dynamic linker itself, PROT_BTI protection is done by the
> operating system.
>
> On AArch64 glibc uses PT_GNU_PROPERTY instead of PT_NOTE to check
> the properties of a binary because PT_NOTE can be unreliable with
> old linkers (old linkers just append the notes of input objects
> together and add them to the output without checking them for
> consistency which means multiple incompatible GNU property notes
> can be present in PT_NOTE). A new _dl_process_pt_gnu_property
> hook is introduced in dl-prop.h and to keep it maintainable the
> rtld and dlopen code paths use the same function (if the main
> map needs special treatment, that should be inferred by the hook
> from the link map). Unlike the _dt_process_pt_note hook this one
> is called after segments are mapped to avoid unbounded allocation
> and additional read syscall. Otherwise the AArch64 logic follows
> the x86 logic for handling GNU properties (but the code is not
> shared because x86 needs to manage internal CET state and look
> out for multiple property notes).

Can you make _dl_process_pt_gnu_property more generic so that it
can be shared with x86?  If there is PT_GNU_PROPERTY, we don't
need to check for multiple property notes.  Thanks.

> BTI property is handled in the loader even if glibc is not built
> with BTI support, so in theory user code can be BTI protected
> independently of glibc. In practice though user binaries are not
> marked with the BTI property if glibc has no support because the
> static linked libc objects (crt files, libc_nonshared.a) are
> unmarked.
>
> This patch relies on Linux userspace API that is scheduled to be
> merged in Linux 5.8 and now it is in the for-next/bti-user branch
> of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git.
>

-- 
H.J.