Re: [PATCH v2 01/10] arm64: bti: Support building kernel C code using BTI

Amit Kachhap
2020-05-06T12:25:15Z

Hi,

On 5/5/20 11:01 PM, Mark Brown wrote:
> On Tue, May 05, 2020 at 05:50:45PM +0100, Dave Martin wrote:
>> On Wed, Apr 29, 2020 at 10:16:32PM +0100, Mark Brown wrote:
>
>>> +ifeq ($(CONFIG_ARM64_BTI_KERNEL),y)
>>> +branch-prot-flags-$(CONFIG_CC_HAS_BRANCH_PROT_PAC_RET_BTI) := -mbranch-protection=pac-ret+leaf+bti
>>> +else
>>> branch-prot-flags-$(CONFIG_CC_HAS_BRANCH_PROT_PAC_RET) := -mbranch-protection=pac-ret+leaf
>>> +endif
>
>> Is it worth a comment to explain how this differs from
>> -mbranch-protection=standard, and why we're not using that here?
>
> There was some open discussion in a separate thread about the use of
> +leaf:
>
> https://lore.kernel.org/linux-arm-kernel/1588149371-20310-1-git-send-email-amit.kachhap@arm.com/
>
> which currently settled on leaving it in but I do agree, it probably
> would be useful to document the choices we're making here. CCing Amit
> as some of the discussion was off-list so I don't know all the details
> there.

It was decided to retain the strictest ptrauth compiler option as there
is a narrow scope of ROP protection use-case in case of leaf function.
Although I provided some static benefits in diluting this requirement
but it was suggested to differ it till there is some run-time
performance gain data for leaf functions.

Yes documenting it here makes sense.

Cheers,
Amit Daniel

>
> As with the recent change to explicitly default to branch-protection=none
> there's probably a case for simply being explicit about whatever we're
> doing rather than relying on compiler defaults in case there are any bad
> interactions with code generated for an extension that isn't fully
> supported in the kernel in the future.
>