Claudiu Zissulescu-Ianculescu <claudiu.zissulescu-iancule...@oracle.com> writes:
> Hi,
>
>>> +DEFHOOK
>>> +(compose_offset_tag,
>>> + "Return an RTX that represnts the result of composing
>>> @var{tag_offset} with\n\
>>> +the base tag @var{base_tag}.\n\
>>> +The default of this hook is to byte add @var{tag_offset} to
>>> @var{base_tag}.",
>>> + rtx, (rtx base_tag, uint8_t tag_offset),
>>> default_memtag_compose_offset_tag)
>>> +
>>
>> I can't remember whether this was the result of a previous discussion,
>> sorry, but I'm not sure about the interface. It seems that "base_tag"
>> really is a tag for the hwasan case, but is actually a tagged address
>> for MTE. It therefore feels like these are two separate operations.
>
> This was not in the previous discussions. My problem was that in asan.c
> the tag operations are done on the extracted tag, while in the case of
> MTE, we can operated directly on the address-tag tuple using addg/subg
> instructions. Thus, I've introduced this hook which in the case of MTE
> will use addg/subg instructions when we want to add the tag, otherwise,
> a simple add of the input tag and offset is used. The purpose here is to
> avoid extraction/insertion of the tag as much as possible as well as
> changing the asan code only when it is really needed.
>
>>
>> Since there is no immediate need to put the current hwasan behaviour
>> behind a hook, how about defining an interface specifically for memtag
>> sanitisation that explicitly has a tagged base address as its first
>> operand?
>
> I'll look into it.
> To be clear for me, shall I remove this hook from asan for time being?
I meant instead that the hook could be used only for memtag,
with no default. hwasan could then continue doing what it does now.
But if we're overloading the other hooks in the same way (bare tag
for hwasan, tagged address for memtag), then perhaps doing what I suggest
would be inconsistent. But if we are, I think we should update the
description of the existing hooks to make their dual nature clearer.
>> The memtag behaviour feels more like an optab than a hook to me, but I
>> realise that the other sanitiser stuff is heavily hook-based, so I won't
>> try to push for an optab here.
>>
>
> I've was thinking about an optab but it was bringing too many
> modifications, leading to much more complex patch. In this particular
> case, the design requires to not return an instruction. However, there
> are other hooks which can be converted to optabs, but that will impact
> x86 port. I can make a patch to change hooks to optabs, but I would
> prefer to be separate one.
Like I say, I'm not going to advocate for an optab, so don't feel
under pressure from my POV.
Thanks,
Richard
