[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cca49d1e5da01e9ccdee50d710045fd09005459c.camel@linux.ibm.com>
Date: Mon, 09 Jan 2023 16:20:51 +1100
From: Andrew Donnellan <ajd@...ux.ibm.com>
To: Russell Currey <ruscur@...sell.cc>,
Michael Ellerman <mpe@...erman.id.au>,
linuxppc-dev@...ts.ozlabs.org
Cc: gregkh@...uxfoundation.org, gcwilson@...ux.ibm.com,
linux-kernel@...r.kernel.org, nayna@...ux.ibm.com,
zohar@...ux.ibm.com
Subject: Re: [PATCH v2 7/7] powerpc/pseries: Implement secvars for dynamic
secure boot
On Mon, 2023-01-09 at 14:34 +1100, Russell Currey wrote:
>
> > > +static int plpks_secvar_init(void)
> > > +{
> > > + if (!plpks_is_available())
> > > + return -ENODEV;
> > > +
> > > + set_secvar_ops(&plpks_secvar_ops);
> > > + set_secvar_config_attrs(config_attrs);
> > > + return 0;
> > > +}
> > > +device_initcall(plpks_secvar_init);
> >
> > That must be a machine_device_initcall(pseries, ...), otherwise we
> > will
> > blow up doing a hcall on powernv in plpks_is_available().
>
> OK, can do. I don't understand your case of how powernv could hit
> this, but I think I to have to move plpks_is_available() into
> include/,
> so it's going to be even more possible anyway.
Kernels can be compiled with both pseries and powernv support, in which
case plpks_secvar_init() will be called unconditionally even when
booting on a powernv machine.
I can confirm that as it is, booting this on powernv qemu causes a
panic.
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@...ux.ibm.com IBM Australia Limited
Powered by blists - more mailing lists