[PATCH] arm64: Implement prctl(PR_{G,S}ET_TSC)

[Marc Zyngier]

On Sun, 28 Apr 2024 19:47:56 +0100,
Peter Collingbourne <pcc at google.com> wrote:
> 
> On Sun, Apr 28, 2024 at 3:37 AM Marc Zyngier <maz at kernel.org> wrote:
> >
> > On Sat, 27 Apr 2024 06:27:51 +0100,
> > Peter Collingbourne <pcc at google.com> wrote:
> > >
> > > On arm64, this prctl controls access to CNTVCT_EL0, CNTVCTSS_EL0 and
> > > CNTFRQ_EL0 via CNTKCTL_EL1.EL0VCTEN. Since this bit is also used to
> > > implement various erratum workarounds, check whether the CPU needs
> > > a workaround whenever we potentially need to change it.
> >
> > Why would we ever consider preventing access to CNTVTL_EL0?  This
> > register is part of the arm64 ABI, together with CNTFRQ_EL0.
> > Disabling it also prevents the VDSO from working correctly, making
> > something as simple as getttimeofday() unexpectedly fail.
> >
> > I'm sure you have some rationale behind it, but it is nowhere to be
> > found above, and I cannot see why we'd want to mimic whatever x86
> > does.
> 
> Hi Marc,
> 
> This is needed for a correct implementation of non-instrumenting
> record-replay debugging on arm64 (i.e. rr; https://rr-project.org/).
> rr must trap and record any sources of non-determinism from the
> userspace program's perspective so it can be replayed later. This
> includes the results of syscalls as well as the results of access to
> architected timers exposed directly to the program. rr traps RDTSC on
> x86 for the same reason.

It seems to me that this sort of "trap and inspect" behaviour is in
the realm of ptrace(), and not that of prctl(), because I can't
imagine the debugged program calling that by itself.

My rationale for this is that on x86, TSC wasn't always present. It
was only added fairly late in the game and thus userspace couldn't
always rely on it being present. Which is pretty different from arm64,
which has always had CNTVCT_EL0 and co an integral part of the ABI.

Giving a way to limit the current ABI seems at best odd. On the
contrary, ptrace() does what it says on the tin: it intercepts what
the traced process does.

How does rr work on non-x86 architectures? How does this interoperate
with AArch32?

> I'd be happy to add that to the commit message for v2.

Please, in any case. Possibly with a reference to 8fb402bccf203 so
that people can perform some archaeology on the origins of this thing.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.