| Message ID | 20210602143537.545132-1-stefanb@linux.ibm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add support for ECDSA-signed kernel modules | expand |
On Wed, Jun 02, 2021 at 10:35:35AM -0400, Stefan Berger wrote: > This series adds support for ECDSA-signed kernel modules. It also > attempts to address a kbuild issue where a developer created an ECDSA > key for signing kernel modules and then builds an older version of the > kernel, when bisecting the kernel for example, that does not support > ECDSA keys. > > The first patch addresses the kbuild issue of needing to delete that > ECDSA key if it is in certs/signing_key.pem and trigger the creation > of an RSA key. However, for this to work this patch would have to be > backported to previous versions of the kernel but would also only work > for the developer if he/she used a stable version of the kernel to which > this patch was applied. So whether this patch actually achieves the > wanted effect is not always guaranteed. > > The 2nd patch adds the support for the ECSDA-signed kernel modules. > > This patch depends on the ECDSA support series currently queued here: > https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git/log/?h=ecc > > Stefan > > v5: > - do not touch the key files if openssl is not installed; likely > addresses an issue pointed out by kernel test robot > > v4: > - extending 'depends on' with MODULES to (IMA_APPRAISE_MODSIG && MODULES) > > v3: > - added missing OIDs for ECDSA signed hashes to pkcs7_sig_note_pkey_algo > - added recommendation to use string hash to Kconfig help text > > v2: > - Adjustment to ECDSA key detector string in 2/2 > - Rephrased cover letter and patch descriptions with Mimi > > > Stefan Berger (2): > certs: Trigger creation of RSA module signing key if it's not an RSA > key > certs: Add support for using elliptic curve keys for signing modules > > certs/Kconfig | 26 ++++++++++++++++++++++++++ > certs/Makefile | 21 +++++++++++++++++++++ > crypto/asymmetric_keys/pkcs7_parser.c | 8 ++++++++ > 3 files changed, 55 insertions(+) > > -- > 2.29.2 > > Please instead send a fix. /Jarkko
On 6/3/21 2:47 AM, Jarkko Sakkinen wrote: > >> -- >> 2.29.2 >> >> > Please instead send a fix. We have a Fixes tag in 1/2, so we want this to propagate to older kernels and need the fix in 1/2 for that reason. Stefan
On Thu, Jun 03, 2021 at 08:32:59AM -0400, Stefan Berger wrote: > > On 6/3/21 2:47 AM, Jarkko Sakkinen wrote: > > > > > -- > > > 2.29.2 > > > > > > > > Please instead send a fix. > > We have a Fixes tag in 1/2, so we want this to propagate to older kernels > and need the fix in 1/2 for that reason. > > Stefan So please do an additional fix and send it. /Jarkko
On 6/9/21 8:44 AM, Jarkko Sakkinen wrote: > On Thu, Jun 03, 2021 at 08:32:59AM -0400, Stefan Berger wrote: >> On 6/3/21 2:47 AM, Jarkko Sakkinen wrote: >>>> -- >>>> 2.29.2 >>>> >>>> >>> Please instead send a fix. >> We have a Fixes tag in 1/2, so we want this to propagate to older kernels >> and need the fix in 1/2 for that reason. >> >> Stefan > So please do an additional fix and send it. 1/2 is supposed to propagate to older kernels and needs to change as posted here in v5 (assuming that this does indeed fix what the build bot was complaining about). 2/2 also changes. A fix on top of v4 would fix 2/2 but won't apply cleanly to 1/2 as cannot easily propagate to older kernels. Is that what we want? Why can you not remove v4 from your queue and replace it with v5? Stefan
On Wed, Jun 09, 2021 at 09:58:29AM -0400, Stefan Berger wrote: > > On 6/9/21 8:44 AM, Jarkko Sakkinen wrote: > > On Thu, Jun 03, 2021 at 08:32:59AM -0400, Stefan Berger wrote: > > > On 6/3/21 2:47 AM, Jarkko Sakkinen wrote: > > > > > -- > > > > > 2.29.2 > > > > > > > > > > > > > > Please instead send a fix. > > > We have a Fixes tag in 1/2, so we want this to propagate to older kernels > > > and need the fix in 1/2 for that reason. > > > > > > Stefan > > So please do an additional fix and send it. > > 1/2 is supposed to propagate to older kernels and needs to change as posted > here in v5 (assuming that this does indeed fix what the build bot was > complaining about). 2/2 also changes. A fix on top of v4 would fix 2/2 but > won't apply cleanly to 1/2 as cannot easily propagate to older kernels. Is > that what we want? Why can you not remove v4 from your queue and replace it > with v5? > > Stefan What you can do is to send fix or fixes with appropriate fixes tags and I can then squash them for appropriate patches. That's less work for me. /Jarkko
On 6/10/21 5:03 AM, Jarkko Sakkinen wrote: > On Wed, Jun 09, 2021 at 09:58:29AM -0400, Stefan Berger wrote: >> On 6/9/21 8:44 AM, Jarkko Sakkinen wrote: >>> On Thu, Jun 03, 2021 at 08:32:59AM -0400, Stefan Berger wrote: >>>> On 6/3/21 2:47 AM, Jarkko Sakkinen wrote: >>>>>> -- >>>>>> 2.29.2 >>>>>> >>>>>> >>>>> Please instead send a fix. >>>> We have a Fixes tag in 1/2, so we want this to propagate to older kernels >>>> and need the fix in 1/2 for that reason. >>>> >>>> Stefan >>> So please do an additional fix and send it. >> 1/2 is supposed to propagate to older kernels and needs to change as posted >> here in v5 (assuming that this does indeed fix what the build bot was >> complaining about). 2/2 also changes. A fix on top of v4 would fix 2/2 but >> won't apply cleanly to 1/2 as cannot easily propagate to older kernels. Is >> that what we want? Why can you not remove v4 from your queue and replace it >> with v5? >> >> Stefan > What you can do is to send fix or fixes with appropriate fixes tags and > I can then squash them for appropriate patches. That's less work for me. Once you squash a fix on top of existing 1/2 , existing 2/2 will not apply anymore. I am not sure what to send you. I think it would take less time to remove the existing 2 patches and replace them with v5. Stefan
This series adds support for ECDSA-signed kernel modules. It also attempts to address a kbuild issue where a developer created an ECDSA key for signing kernel modules and then builds an older version of the kernel, when bisecting the kernel for example, that does not support ECDSA keys. The first patch addresses the kbuild issue of needing to delete that ECDSA key if it is in certs/signing_key.pem and trigger the creation of an RSA key. However, for this to work this patch would have to be backported to previous versions of the kernel but would also only work for the developer if he/she used a stable version of the kernel to which this patch was applied. So whether this patch actually achieves the wanted effect is not always guaranteed. The 2nd patch adds the support for the ECSDA-signed kernel modules. This patch depends on the ECDSA support series currently queued here: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git/log/?h=ecc Stefan v5: - do not touch the key files if openssl is not installed; likely addresses an issue pointed out by kernel test robot v4: - extending 'depends on' with MODULES to (IMA_APPRAISE_MODSIG && MODULES) v3: - added missing OIDs for ECDSA signed hashes to pkcs7_sig_note_pkey_algo - added recommendation to use string hash to Kconfig help text v2: - Adjustment to ECDSA key detector string in 2/2 - Rephrased cover letter and patch descriptions with Mimi Stefan Berger (2): certs: Trigger creation of RSA module signing key if it's not an RSA key certs: Add support for using elliptic curve keys for signing modules certs/Kconfig | 26 ++++++++++++++++++++++++++ certs/Makefile | 21 +++++++++++++++++++++ crypto/asymmetric_keys/pkcs7_parser.c | 8 ++++++++ 3 files changed, 55 insertions(+)