[PATCH] Fix runtime linker auditing on aarch64

[Szabolcs Nagy]

The 09/23/2020 14:56, Florian Weimer wrote:
> * Szabolcs Nagy:
> > The 09/23/2020 14:22, Florian Weimer via Libc-alpha wrote:
> >> * Ben Woodard via Libc-alpha:
> >> 
> >> > To fix this
> >> >   * The La_aarch64_regs structure was expanded to include x8 and the full
> >> >     sized NEON V registers that are required to be preserved by the ABI.
> >> 
> >> Off-list, you said that the audit interface was completely broken on
> >> AArch64.  But it seems to be working enough for sotruss.  So I do wonder
> >> if we have to do a proper ABI transition here after all (bumping
> >> LAV_CURRENT and all the consequences of that).
> >
> > i think plt hooks currently don't work for functions
> > that take neon vector arguments because the save/restore
> > logic clobbers the top bits (but such extern calls are
> > not common since they need to use non-portable types)
> >
> > but i agree if it's not too intrusive to bump the audit
> > abi then we should do so and then the incompatibility
> > can be detected at least.
> 
> The other question I had if we can do this once and make sure that the
> CPU state is represented in such a way that we can efficiently save and
> load it for later SVE support, so that we do not have to create two
> copies (the architecture state and the audit representation), or bump
> LAV_CURRENT for a new CPU.
> 
> (I'm aware that AArch64 would be pioneering audit support for vector
> calling conventions.)

we don't have a way to do this in the architecture
(i.e. reg state save/restore operations)
we can have something in the kernel (which needs
to know about the supported registers) but i
assume using a syscall for this is too much overhead.
(maybe in vdso? sounds ugly if we need it before
vdso is set up)

(i can tell the architects about this requirement
in case they invent new register state.)