Re: [PATCH 1/2] target/arm: Add cpu property to control pauth

[Mark Rutland]

On Thu, Aug 13, 2020 at 11:49:07AM +0200, Andrew Jones wrote:
> On Thu, Aug 13, 2020 at 10:05:04AM +0100, Mark Rutland wrote:
> > On Thu, Aug 13, 2020 at 08:03:21AM +0200, Andrew Jones wrote:
> > > Thinking about this some more, maybe we don't need pauth-arch.
> > > If we don't, then it simplifies nicely to
> > > 
> > >  # Default (enabled with architected algorithm)
> > >  -cpu max[,pauth=on][,pauth-fast=off]
> > > 
> > >  # Select pauth-fast
> > >  -cpu max[,pauth=on],pauth-fast=on
> > 
> > One reason that users may wish to choose the IMP-DEF algorithm is for
> > functional testing regardless of speed (since APA+GPA / API+GPI depend
> > on whether the algo is architected or imp-def).
> > 
> > Given that, I think that "impdef" is a better option name than
> > "pauth-fast", and speed is a benefit but not the only reason to use the
> > option.
> 
> I was going with pauth-fast because in this case Richard identified a
> need for a fast version. If we identify another need later, then we may
> want to add another impdef version, e.g. pauth-foo. Maybe all the impdef
> versions should have impdef in their name to make that more explicit?
> 
>  pauth-impdef-fast
>  pauth-impdef-foo

Something like that is fine by me.

> > How about hacing a 'pauth-algo' option which defaults to architected,
> > e.g.
> > 
> > | -cpu max,pauth={on,off},pauth-algo={impdef,architected}
> > 
> > ... then in future the 'pauth={on,off}' bit could de extended to cover
> > FPAC version etc independently of the algorithm, but for now that can be
> > a boolean.
> 
> Keeping pauth a boolean, but creating a pauth-algo enum doesn't help us
> much, because probing will only be possible for pauth. The prober could
> only decide to enable pauth with the default algo or not. We could create
> a pauth-specific probe, similar to the gic-specific probe, but, IMO, it's
> really not necessary. If we need multiple pauth-* properties, then we can
> have them all. It just adds a few more lines of logic to the pauth
> finalize function.

I suspect that it will be necessary in future handle multiple options to
enumerate things like FPAC/EPAC separately from the algorithm used,
which is why I suggested the algo being its own option now.

I can live with whatever you folk decide on.

Thanks,
Mark.