[PATCH] kasan: arm64: support specialized outlined tag mismatch checks

[Mark Rutland]

On Fri, Nov 20, 2020 at 02:59:42PM -0800, Peter Collingbourne wrote:
> On Fri, Nov 13, 2020 at 3:22 AM Mark Rutland <mark.rutland at arm.com> wrote:
> Hi Mark,
> 
> I think all of your suggestions may be considered useful improvements
> to the ABI, and if we were redesigning it from scratch then I think it
> would look a lot more like what you've proposed. However, as discussed
> out-of-band, the ABI is already being used in userspace, and has been
> for over a year, and I don't think any of them rise to the level of
> justifying creating a new ABI, in particular because they only affect
> the uncommon case where we've actually detected an error.

Sure, and apologies for the confusion here.  I had sent this email just
before that out-of-band conversation, and as mentioned there I wasn't
aware this was an existing ABI.

Given that, my main concerns are that this works correctly with PLTs
(which as below, it should) and reliable stacktrace (which it appears it
should as it affectively makes a tail-call), and that we thoroughly
document the calling convention since it is surprising.

I see you've sent a v2, and I'll follow up there.

> > > For reference here is an example of a trampoline function for the kernel:
> > >
> > > __hwasan_check_x1_67043328:
> > > sbfx x16, x1, #4, #52
> > > ldrb w16, [x9, x16]
> > > cmp x16, x1, lsr #56
> > > b.ne .Ltmp5
> > > .Ltmp6:
> > > ret
> > > .Ltmp5:
> > > lsr x16, x1, #56
> > > cmp x16, #255
> > > b.eq .Ltmp6
> > > stp x0, x1, [sp, #-256]!
> > > stp x29, x30, [sp, #232]
> > > mov x0, x1
> > > mov x1, #0
> > > b __hwasan_tag_mismatch
> >
> > Thanks for this; it was helpful in clarifying my understanding.
> >
> > I note this clobbers x16 unconditionally. Is x17 free for use too?
> 
> Yes, and indeed it must be free for use because the linker is allowed
> to clobber x16 and x17 across the call via a range extension thunk
> (that said, I don't know what ld.bfd does, but ld.lld just clobbers
> x16).

Sure, that range extension thunk or PLT was exactly what I was
concerned with, since I wasn't sure which portions of the usual AAPCS
rules were being respected here. Thanks for confirming!

Thanks,
Mark.