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

[Robert O'Callahan]

[CCing Oleg since people are proposing to extend ptrace.]

On Sat, 17 Aug 2024 at 07:04, Peter Collingbourne <pcc at google.com> wrote:
>
> So if it has to be a ptrace() API, then I think
> it needs to be an opt-in to putting the process into a stopped state
> upon reading CNTVCT_EL0.

Yes, this is right. It's essential to be able to trap on read.

One thing to consider is extensibility. It is very likely that we will
want to be able to put additional register types under this "trap on
read" discipline; on x86 we added trap-on-CPUID, for example. So what
would this hypothetical ptrace API look like? We would probably only
need one new stop type that covers all instruction traps, since the
tracer can disambiguate which instruction was to be executed (except
in bizarre edge cases like racing tasks modifying the code, which the
x86 signal-on-trap doesn't handle either). But we would need to add
successive opt-ins for new instruction types. We wouldn't want to eat
up PTRACE_O_ options. So I think we'd need a new ptrace command, e.g.
PTRACE_SET_INSTRUCTION_STOP with a flags argument whose interpretation
is architecture dependent.

(Personally I still agree with Peter, Kyle and Keno that a prctl would
be better than new ptrace API. Sooner or later someone is going to
want this functionality without having to ptrace the target, e.g. by
taking a signal and emulating the instruction in the signal handler.)

Rob
-- 
Su ot deraeppa sah dna Rehtaf eht htiw saw hcihw, efil lanrete eht uoy
ot mialcorp ew dna, ti ot yfitset dna ti nees evah ew; deraeppa efil
eht. Efil fo Drow eht gninrecnoc mialcorp ew siht - dehcuot evah sdnah
ruo dna ta dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw,
draeh evah ew hcihw, gninnigeb eht morf saw hcihw taht.