[v4,0/2] let kexec_file_load use platform keyring to verify the kernel image
mbox series

Message ID 20190118091733.29940-1-kasong@redhat.com
Headers show
Series
  • let kexec_file_load use platform keyring to verify the kernel image
Related show

Message

Kairui Song Jan. 18, 2019, 9:17 a.m. UTC
This patch series adds a .platform_trusted_keys in system_keyring as the
reference to .platform keyring in integrity subsystem, when platform
keyring is being initialized it will be updated. So other component could
use this keyring as well.

This patch series also let kexec_file_load use platform keyring as fall
back if it failed to verify the image against secondary keyring, make it
possible to load kernel signed by keys provides by firmware.

After this patch kexec_file_load will be able to verify a signed PE
bzImage using keys in platform keyring.

Tested in a VM with locally signed kernel with pesign and imported the
cert to EFI's MokList variable.

To test this patch series on latest kernel, you need to ensure this commit
is applied as there is an regression bug in sanity_check_segment_list():

https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=993a110319a4a60aadbd02f6defdebe048f7773b

Update from V3:
  - Tweak and simplify commit message as suggested by Mimi Zohar

Update from V2:
  - Use IS_ENABLED in kexec_file_load to judge if platform_trusted_keys
    should be used for verifying image as suggested by Mimi Zohar

Update from V1:
  - Make platform_trusted_keys static, and update commit message as suggested
    by Mimi Zohar
  - Always check if platform keyring is initialized before use it

Kairui Song (2):
  integrity, KEYS: add a reference to platform keyring
  kexec, KEYS: Make use of platform keyring for signature verify

 arch/x86/kernel/kexec-bzimage64.c | 13 ++++++++++---
 certs/system_keyring.c            | 22 +++++++++++++++++++++-
 include/keys/system_keyring.h     |  5 +++++
 include/linux/verification.h      |  1 +
 security/integrity/digsig.c       |  6 ++++++
 5 files changed, 43 insertions(+), 4 deletions(-)

Comments

Mimi Zohar Jan. 18, 2019, 11:53 a.m. UTC | #1
On Fri, 2019-01-18 at 17:17 +0800, Kairui Song wrote:
> This patch series adds a .platform_trusted_keys in system_keyring as the
> reference to .platform keyring in integrity subsystem, when platform
> keyring is being initialized it will be updated. So other component could
> use this keyring as well.

Kairui, when people review patches, the comments could be specific,
but are normally generic.  My review included a couple of generic
suggestions - not to use "#ifdef" in C code (eg. is_enabled), use the
term "preboot" keys, and remove any references to "other components".

After all the wording suggestions I've made, you are still saying, "So
other components could use this keyring as well".  Really?!  How the
platform keyring will be used in the future, is up to you and others
to convince Linus.  At least for now, please limit its usage to
verifying the PE signed kernel image.  If this patch set needs to be
reposted, please remove all references to "other components".

Dave/David, are you ok with Kairui's usage of "#ifdef's"?  Dave, you
Acked the original post.  Can I include it?  Can we get some
additional Ack's on these patches?

thanks!

Mimi


> 
> This patch series also let kexec_file_load use platform keyring as fall
> back if it failed to verify the image against secondary keyring, make it
> possible to load kernel signed by keys provides by firmware.
> 
> After this patch kexec_file_load will be able to verify a signed PE
> bzImage using keys in platform keyring.
> 
> Tested in a VM with locally signed kernel with pesign and imported the
> cert to EFI's MokList variable.
> 
> To test this patch series on latest kernel, you need to ensure this commit
> is applied as there is an regression bug in sanity_check_segment_list():
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=993a110319a4a60aadbd02f6defdebe048f7773b
> 
> Update from V3:
>   - Tweak and simplify commit message as suggested by Mimi Zohar
> 
> Update from V2:
>   - Use IS_ENABLED in kexec_file_load to judge if platform_trusted_keys
>     should be used for verifying image as suggested by Mimi Zohar
> 
> Update from V1:
>   - Make platform_trusted_keys static, and update commit message as suggested
>     by Mimi Zohar
>   - Always check if platform keyring is initialized before use it
> 
> Kairui Song (2):
>   integrity, KEYS: add a reference to platform keyring
>   kexec, KEYS: Make use of platform keyring for signature verify
> 
>  arch/x86/kernel/kexec-bzimage64.c | 13 ++++++++++---
>  certs/system_keyring.c            | 22 +++++++++++++++++++++-
>  include/keys/system_keyring.h     |  5 +++++
>  include/linux/verification.h      |  1 +
>  security/integrity/digsig.c       |  6 ++++++
>  5 files changed, 43 insertions(+), 4 deletions(-)
>
Kairui Song Jan. 18, 2019, 12:07 p.m. UTC | #2
On Fri, Jan 18, 2019, 19:54 Mimi Zohar <zohar@linux.ibm.com wrote:
>
> On Fri, 2019-01-18 at 17:17 +0800, Kairui Song wrote:
> > This patch series adds a .platform_trusted_keys in system_keyring as the
> > reference to .platform keyring in integrity subsystem, when platform
> > keyring is being initialized it will be updated. So other component could
> > use this keyring as well.
>
> Kairui, when people review patches, the comments could be specific,
> but are normally generic.  My review included a couple of generic
> suggestions - not to use "#ifdef" in C code (eg. is_enabled), use the
> term "preboot" keys, and remove any references to "other components".
>
> After all the wording suggestions I've made, you are still saying, "So
> other components could use this keyring as well".  Really?!  How the
> platform keyring will be used in the future, is up to you and others
> to convince Linus.  At least for now, please limit its usage to
> verifying the PE signed kernel image.  If this patch set needs to be
> reposted, please remove all references to "other components".
>
> Dave/David, are you ok with Kairui's usage of "#ifdef's"?  Dave, you
> Acked the original post.  Can I include it?  Can we get some
> additional Ack's on these patches?
>
> thanks!
>
> Mimi
>

Hi, Mimi, thanks for your feedback. My bad I reused the old cover
letter without checking it carefully, hopefully, the commit messages
should have a proper wording now. If the cover letter needs to be
updated I can resend the patch, let me just hold a while before update
again.
Dave Young Jan. 18, 2019, 12:34 p.m. UTC | #3
On 01/18/19 at 06:53am, Mimi Zohar wrote:
> On Fri, 2019-01-18 at 17:17 +0800, Kairui Song wrote:
> > This patch series adds a .platform_trusted_keys in system_keyring as the
> > reference to .platform keyring in integrity subsystem, when platform
> > keyring is being initialized it will be updated. So other component could
> > use this keyring as well.
> 
> Kairui, when people review patches, the comments could be specific,
> but are normally generic.  My review included a couple of generic
> suggestions - not to use "#ifdef" in C code (eg. is_enabled), use the
> term "preboot" keys, and remove any references to "other components".
> 
> After all the wording suggestions I've made, you are still saying, "So
> other components could use this keyring as well".  Really?!  How the
> platform keyring will be used in the future, is up to you and others
> to convince Linus.  At least for now, please limit its usage to
> verifying the PE signed kernel image.  If this patch set needs to be
> reposted, please remove all references to "other components".
> 
> Dave/David, are you ok with Kairui's usage of "#ifdef's"?  Dave, you
> Acked the original post.  Can I include it?  Can we get some
> additional Ack's on these patches?

It is better to update patch to use IS_ENABLED in patch 1/2 as well.
Other than that, for kexec part I'm fine with an ack.
 
Thanks
Dave
Dave Young Jan. 18, 2019, 12:37 p.m. UTC | #4
On 01/18/19 at 08:34pm, Dave Young wrote:
> On 01/18/19 at 06:53am, Mimi Zohar wrote:
> > On Fri, 2019-01-18 at 17:17 +0800, Kairui Song wrote:
> > > This patch series adds a .platform_trusted_keys in system_keyring as the
> > > reference to .platform keyring in integrity subsystem, when platform
> > > keyring is being initialized it will be updated. So other component could
> > > use this keyring as well.
> > 
> > Kairui, when people review patches, the comments could be specific,
> > but are normally generic.  My review included a couple of generic
> > suggestions - not to use "#ifdef" in C code (eg. is_enabled), use the
> > term "preboot" keys, and remove any references to "other components".
> > 
> > After all the wording suggestions I've made, you are still saying, "So
> > other components could use this keyring as well".  Really?!  How the
> > platform keyring will be used in the future, is up to you and others
> > to convince Linus.  At least for now, please limit its usage to
> > verifying the PE signed kernel image.  If this patch set needs to be
> > reposted, please remove all references to "other components".
> > 
> > Dave/David, are you ok with Kairui's usage of "#ifdef's"?  Dave, you
> > Acked the original post.  Can I include it?  Can we get some
> > additional Ack's on these patches?
> 
> It is better to update patch to use IS_ENABLED in patch 1/2 as well.

Hmm, not only for patch 1/2, patch 2/2 also need an update

> Other than that, for kexec part I'm fine with an ack.
>  
> Thanks
> Dave
Kairui Song Jan. 18, 2019, 1:42 p.m. UTC | #5
On Fri, Jan 18, 2019 at 8:37 PM Dave Young <dyoung@redhat.com> wrote:
>
> On 01/18/19 at 08:34pm, Dave Young wrote:
> > On 01/18/19 at 06:53am, Mimi Zohar wrote:
> > > On Fri, 2019-01-18 at 17:17 +0800, Kairui Song wrote:
> > > > This patch series adds a .platform_trusted_keys in system_keyring as the
> > > > reference to .platform keyring in integrity subsystem, when platform
> > > > keyring is being initialized it will be updated. So other component could
> > > > use this keyring as well.
> > >
> > > Kairui, when people review patches, the comments could be specific,
> > > but are normally generic.  My review included a couple of generic
> > > suggestions - not to use "#ifdef" in C code (eg. is_enabled), use the
> > > term "preboot" keys, and remove any references to "other components".
> > >
> > > After all the wording suggestions I've made, you are still saying, "So
> > > other components could use this keyring as well".  Really?!  How the
> > > platform keyring will be used in the future, is up to you and others
> > > to convince Linus.  At least for now, please limit its usage to
> > > verifying the PE signed kernel image.  If this patch set needs to be
> > > reposted, please remove all references to "other components".
> > >
> > > Dave/David, are you ok with Kairui's usage of "#ifdef's"?  Dave, you
> > > Acked the original post.  Can I include it?  Can we get some
> > > additional Ack's on these patches?
> >
> > It is better to update patch to use IS_ENABLED in patch 1/2 as well.
>
> Hmm, not only for patch 1/2, patch 2/2 also need an update
>
> > Other than that, for kexec part I'm fine with an ack.
> >
> > Thanks
> > Dave

Thanks for the review again, will update the patch using IS_ENABLED
along with update the cover letter shortly.
Kairui Song Jan. 18, 2019, 2:28 p.m. UTC | #6
On Fri, Jan 18, 2019 at 9:42 PM Kairui Song <kasong@redhat.com> wrote:
>
> On Fri, Jan 18, 2019 at 8:37 PM Dave Young <dyoung@redhat.com> wrote:
> >
> > On 01/18/19 at 08:34pm, Dave Young wrote:
> > > On 01/18/19 at 06:53am, Mimi Zohar wrote:
> > > > On Fri, 2019-01-18 at 17:17 +0800, Kairui Song wrote:
> > > > > This patch series adds a .platform_trusted_keys in system_keyring as the
> > > > > reference to .platform keyring in integrity subsystem, when platform
> > > > > keyring is being initialized it will be updated. So other component could
> > > > > use this keyring as well.
> > > >
> > > > Kairui, when people review patches, the comments could be specific,
> > > > but are normally generic.  My review included a couple of generic
> > > > suggestions - not to use "#ifdef" in C code (eg. is_enabled), use the
> > > > term "preboot" keys, and remove any references to "other components".
> > > >
> > > > After all the wording suggestions I've made, you are still saying, "So
> > > > other components could use this keyring as well".  Really?!  How the
> > > > platform keyring will be used in the future, is up to you and others
> > > > to convince Linus.  At least for now, please limit its usage to
> > > > verifying the PE signed kernel image.  If this patch set needs to be
> > > > reposted, please remove all references to "other components".
> > > >
> > > > Dave/David, are you ok with Kairui's usage of "#ifdef's"?  Dave, you
> > > > Acked the original post.  Can I include it?  Can we get some
> > > > additional Ack's on these patches?
> > >
> > > It is better to update patch to use IS_ENABLED in patch 1/2 as well.
> >
> > Hmm, not only for patch 1/2, patch 2/2 also need an update
> >
> > > Other than that, for kexec part I'm fine with an ack.
> > >
> > > Thanks
> > > Dave
>
> Thanks for the review again, will update the patch using IS_ENABLED
> along with update the cover letter shortly.
>
> --
> Best Regards,
> Kairui Song

Hi, before I update it again, most part of the new
platform_trusted_keyring related code is following how
secondary_trusted_keyring is implemented (surrounded by ifdefs). I
thought this could reduce unused code when the keyring is not enabled.
Else, all ifdef could be simply removed, when platform_keyring is not
enabled, the platform_trusted_keys will always be NULL, and
verify_pkcs7_signature will simply return NOKEY if anyone try to use
platform keyring.

Any suggestions? Or I can just remove the ifdef in
security/integrity/digsig.c and make set_platform_trusted_keys a
inline empty function in system_keyring.h.
Kairui Song Jan. 21, 2019, 9:08 a.m. UTC | #7
On Fri, Jan 18, 2019 at 10:28 PM Kairui Song <kasong@redhat.com> wrote:
>
> On Fri, Jan 18, 2019 at 9:42 PM Kairui Song <kasong@redhat.com> wrote:
> >
> > On Fri, Jan 18, 2019 at 8:37 PM Dave Young <dyoung@redhat.com> wrote:
> > >
> > > On 01/18/19 at 08:34pm, Dave Young wrote:
> > > > On 01/18/19 at 06:53am, Mimi Zohar wrote:
> > > > > On Fri, 2019-01-18 at 17:17 +0800, Kairui Song wrote:
> > > > > > This patch series adds a .platform_trusted_keys in system_keyring as the
> > > > > > reference to .platform keyring in integrity subsystem, when platform
> > > > > > keyring is being initialized it will be updated. So other component could
> > > > > > use this keyring as well.
> > > > >
> > > > > Kairui, when people review patches, the comments could be specific,
> > > > > but are normally generic.  My review included a couple of generic
> > > > > suggestions - not to use "#ifdef" in C code (eg. is_enabled), use the
> > > > > term "preboot" keys, and remove any references to "other components".
> > > > >
> > > > > After all the wording suggestions I've made, you are still saying, "So
> > > > > other components could use this keyring as well".  Really?!  How the
> > > > > platform keyring will be used in the future, is up to you and others
> > > > > to convince Linus.  At least for now, please limit its usage to
> > > > > verifying the PE signed kernel image.  If this patch set needs to be
> > > > > reposted, please remove all references to "other components".
> > > > >
> > > > > Dave/David, are you ok with Kairui's usage of "#ifdef's"?  Dave, you
> > > > > Acked the original post.  Can I include it?  Can we get some
> > > > > additional Ack's on these patches?
> > > >
> > > > It is better to update patch to use IS_ENABLED in patch 1/2 as well.
> > >
> > > Hmm, not only for patch 1/2, patch 2/2 also need an update
> > >
> > > > Other than that, for kexec part I'm fine with an ack.
> > > >
> > > > Thanks
> > > > Dave
> >
> > Thanks for the review again, will update the patch using IS_ENABLED
> > along with update the cover letter shortly.
> >
> > --
> > Best Regards,
> > Kairui Song
>
> Hi, before I update it again, most part of the new
> platform_trusted_keyring related code is following how
> secondary_trusted_keyring is implemented (surrounded by ifdefs). I
> thought this could reduce unused code when the keyring is not enabled.
> Else, all ifdef could be simply removed, when platform_keyring is not
> enabled, the platform_trusted_keys will always be NULL, and
> verify_pkcs7_signature will simply return NOKEY if anyone try to use
> platform keyring.
>
> Any suggestions? Or I can just remove the ifdef in
> security/integrity/digsig.c and make set_platform_trusted_keys a
> inline empty function in system_keyring.h.
>
> --
> Best Regards,
> Kairui Song

Hi, after a second thought I'll drop the #ifdef in
security/integrity/digsig.c in PATCH 1/2, and make the
set_platform_trusted_keys function a empty inline function when
CONFIG_INTEGRITY_PLATFORM_KEYRING is undefined.
But for other ifdefs in certs/system_keyring.c I think maybe just keep
then untouched. They were used to strip out the
platform_trusted_keyring variable and related function when
CONFIG_INTEGRITY_PLATFORM_KEYRING is not used, this should help reduce
unused code and prevent compile error, also make code style aligns
with existing code in system_keyring.c.

Will sent v5 with above updates and fix a potential problem found by Nayna.


--
Best Regards,
Kairui Song