On Fri, Jan 04, 2019 at 10:33:40AM +0100, Pavel Machek wrote:
> On Fri 2019-01-04 09:21:30, Marc Zyngier wrote:
> > On 03/01/2019 20:29, Pavel Machek wrote:
> > > On Fri 2018-12-07 18:39:25, Kristina Martsenko wrote:
> > >> From: Mark Rutland <mark.rutland@xxxxxxx>
> > >>
> > >> This patch adds basic support for pointer authentication,
> > >> allowing userspace to make use of APIAKey, APIBKey, APDAKey,
> > >> APDBKey, and APGAKey. The kernel maintains key values for each
> > >> process (shared by all threads within), which are initialised to
> > >> random values at exec()
> > > time.
> > >
> > > ...
> > >
> > >> +/* + * We give each process its own keys, which are shared by
> > >> all threads. The keys + * are inherited upon fork(), and
> > >> reinitialised upon exec*(). + */ +struct ptrauth_keys { + struct
> > >> ptrauth_key apia; + struct ptrauth_key apib; + struct ptrauth_key
> > >> apda; + struct ptrauth_key apdb; + struct ptrauth_key apga; +};
> > >
> > > intstruction_a, data_a, generic_a? Should be easier to understand
> > > than "apdb" ...
> >
> > ... until you realize that these names do match the documentation,
> > which makes it even easier to understand how the code uses the
> > architecture.
>
> See how not even the commit log matches the documentation then?
The commit message exactly matches the documentation, as it refers to:
APIAKey, APIBKey, APDAKey, APDBKey, and APGAKey
... which are the architected names for those registers, in all the
documentation.
Searching "apga" in the ARM ARM finds all of the relevant information on
APGAKey_EL1. Searching "generic_a" finds precisely nothing, as it's a
term which you invented, that no-one else has previously used.
Likewise for the other key names.
> Naming something "apdb" is just bad... Just because the documentation
> is evil does not mean it should be followed...
It is in no way evil to use the documented names for things.
It is unhelpful to make up terminology that no-one else uses.
Mark.
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
