[PATCH v1 3/3] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
ebiggers at kernel.org
Thu Apr 1 06:03:37 UTC 2021
On Thu, Apr 01, 2021 at 08:50:05AM +0300, Jarkko Sakkinen wrote:
> On Thu, Apr 01, 2021 at 12:11:32PM +1100, Herbert Xu wrote:
> > On Wed, Mar 31, 2021 at 04:34:29PM -0700, Eric Biggers wrote:
> > > On Thu, Apr 01, 2021 at 02:31:46AM +0300, Jarkko Sakkinen wrote:
> > > >
> > > > It's a bummer but uapi is the god in the end. Since TPM does not do it
> > > > today, that behaviour must be supported forever. That's why a boot option
> > > > AND a warning would be the best compromise.
> > >
> > > It's not UAPI if there is no way for userspace to tell if it changed.
> > Exactly. UAPI is only an issue if something *breaks*.
> If there's even one user that comes shouting that he has a user space
> configuration, where e.g. rng entropy is consumed constantly and the
> code assumes that trusted keys does not add to that, then something
> would break.
> It would be a crap user space yes, but I don't want to go on reverting
> because of that. I think there is small but still existing chance that
> something could break.
random.c no longer provides any interfaces that subtract entropy credits, as
that was never something that made sense. So "consuming" all the entropy from
random.c isn't a thing anymore.
> Why not just add a boot parameter instead of making brutal enforcing
> changes, indirectly visible to the user space?
Why not just fix this bug instead of providing an option to fix it that everyone
will need to remember to provide?
More information about the Linux-security-module-archive