Re: [PATCH v3 2/8] elf: Add a tunable to control use of tagged memory

[Richard Earnshaw <Richard.Earnshaw@foss.arm.com>]

On 27/11/2020 10:40, Richard Earnshaw wrote:
> On 27/11/2020 02:45, Siddhesh Poyarekar wrote:
>> On 11/26/20 10:49 PM, H.J. Lu wrote:
>>> The first few questions are
>>
>> OK this is a good start:
>>
>>> 1.  Where should binary markers be checked?
>>
>> At early startup alongside the cpu features resolution.  We enable
>> tagging if the CPU supports MTE and the marker is set.
> 
> I think that's backwards.  The default should be to assume that a binary
> supports tagging and it should only be disabled if the binary explicitly
> says that it is incompatible.
> 
> Requiring a tag to be set before you enable tagging will
> a) Force a complete recompile of all binaries
> b) Result in binaries being incorrectly marked as tagging compatible
> when they aren't (because they won't really be audited until they start
> failing).  They will then have to be rebuilt again without the tag.
> 
> Given b) it then seems obvious that the right way to do this is just to
> mark binaries that are known not to work; after they've been audited to
> make sure that the reason they don't work is legitimate.
> 
>>
>>> 2.  How should binary marker checking work together with tunables?
>>
>> The presence of a binary marker enables tagging and a tunable should not
>> be able to disable it.  The exception would be systemwide tunables[1]
>> where administrators could set sweeping policies for their systems,
>> including disabling tagging systemwide if needed.
>>
>> If binary marker is not present, tunables behave the way it is proposed
>> in the patchset.
>>
>> Siddhesh
>>
>> [1] Vapourware alert!
> 
> R.
> 

Sorry, I meant to add that if this is to be considered a security
feature it should be an active decision to disable it for a specific
binary, not an active decision to enable it.  What's more, the marker
then can be used to quickly find binaries that are tagging unsafe when
targetting things for audit purposes.

R.