| Message ID | cover.1635948742.git.msuchanek@suse.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | KEXEC_SIG with appended signature | expand |
Michal Suchanek <msuchanek@suse.de> writes: > S390 uses appended signature for kernel but implements the check > separately from module loader. > > Support for secure boot on powerpc with appended signature is planned - > grub patches submitted upstream but not yet merged. Power Non-Virtualised / OpenPower already supports secure boot via kexec with signature verification via IMA. I think you have now sent a follow-up series that merges some of the IMA implementation, I just wanted to make sure it was clear that we actually already have support for this in the kernel, it's just grub that is getting new support. > This is an attempt at unified appended signature verification. I am always in favour of fewer reimplementations of the same feature in the kernel :) Regards, Daniel > > Thanks > > Michal > > Michal Suchanek (3): > s390/kexec_file: Don't opencode appended signature verification. > module: strip the signature marker in the verification function. > powerpc/kexec_file: Add KEXEC_SIG support. > > arch/powerpc/Kconfig | 11 +++++++ > arch/powerpc/kexec/elf_64.c | 14 +++++++++ > arch/s390/kernel/machine_kexec_file.c | 42 +++------------------------ > include/linux/verification.h | 3 ++ > kernel/module-internal.h | 2 -- > kernel/module.c | 11 +++---- > kernel/module_signing.c | 32 ++++++++++++++------ > 7 files changed, 59 insertions(+), 56 deletions(-) > > -- > 2.31.1
On Fri, Nov 05, 2021 at 09:55:52PM +1100, Daniel Axtens wrote: > Michal Suchanek <msuchanek@suse.de> writes: > > > S390 uses appended signature for kernel but implements the check > > separately from module loader. > > > > Support for secure boot on powerpc with appended signature is planned - > > grub patches submitted upstream but not yet merged. > > Power Non-Virtualised / OpenPower already supports secure boot via kexec > with signature verification via IMA. I think you have now sent a > follow-up series that merges some of the IMA implementation, I just > wanted to make sure it was clear that we actually already have support So is IMA_KEXEC and KEXEC_SIG redundant? I see some architectures have both. I also see there is a lot of overlap between the IMA framework and the KEXEC_SIG and MODULE_SIg. Thanks Michal
Michal Suchánek <msuchanek@suse.de> writes: > On Fri, Nov 05, 2021 at 09:55:52PM +1100, Daniel Axtens wrote: >> Michal Suchanek <msuchanek@suse.de> writes: >> >> > S390 uses appended signature for kernel but implements the check >> > separately from module loader. >> > >> > Support for secure boot on powerpc with appended signature is planned - >> > grub patches submitted upstream but not yet merged. >> >> Power Non-Virtualised / OpenPower already supports secure boot via kexec >> with signature verification via IMA. I think you have now sent a >> follow-up series that merges some of the IMA implementation, I just >> wanted to make sure it was clear that we actually already have support > > So is IMA_KEXEC and KEXEC_SIG redundant? > > I see some architectures have both. I also see there is a lot of overlap > between the IMA framework and the KEXEC_SIG and MODULE_SIg. Mimi would be much better placed than me to answer this. The limits of my knowledge are basically that signature verification for modules and kexec kernels can be enforced by IMA policies. For example a secure booted powerpc kernel with module support will have the following IMA policy set at the arch level: "appraise func=KEXEC_KERNEL_CHECK appraise_flag=check_blacklist appraise_type=imasig|modsig", (in arch/powerpc/kernel/ima_arch.c) Module signature enforcement can be set with either IMA (policy like "appraise func=MODULE_CHECK appraise_flag=check_blacklist appraise_type=imasig|modsig" ) or with CONFIG_MODULE_SIG_FORCE/module.sig_enforce=1. Sometimes this leads to arguably unexpected interactions - for example commit fa4f3f56ccd2 ("powerpc/ima: Fix secure boot rules in ima arch policy"), so it might be interesting to see if we can make things easier to understand. I suspect another amusing interaction is that if the IMA verification is used, the signature could be in an xattr rather than an appended signature. Kind regards, Daniel
Hello, On Mon, Nov 08, 2021 at 09:18:56AM +1100, Daniel Axtens wrote: > Michal Suchánek <msuchanek@suse.de> writes: > > > On Fri, Nov 05, 2021 at 09:55:52PM +1100, Daniel Axtens wrote: > >> Michal Suchanek <msuchanek@suse.de> writes: > >> > >> > S390 uses appended signature for kernel but implements the check > >> > separately from module loader. > >> > > >> > Support for secure boot on powerpc with appended signature is planned - > >> > grub patches submitted upstream but not yet merged. > >> > >> Power Non-Virtualised / OpenPower already supports secure boot via kexec > >> with signature verification via IMA. I think you have now sent a > >> follow-up series that merges some of the IMA implementation, I just > >> wanted to make sure it was clear that we actually already have support > > > > So is IMA_KEXEC and KEXEC_SIG redundant? > > > > I see some architectures have both. I also see there is a lot of overlap > > between the IMA framework and the KEXEC_SIG and MODULE_SIg. > > > Mimi would be much better placed than me to answer this. > > The limits of my knowledge are basically that signature verification for > modules and kexec kernels can be enforced by IMA policies. > > For example a secure booted powerpc kernel with module support will have > the following IMA policy set at the arch level: > > "appraise func=KEXEC_KERNEL_CHECK appraise_flag=check_blacklist appraise_type=imasig|modsig", > (in arch/powerpc/kernel/ima_arch.c) > > Module signature enforcement can be set with either IMA (policy like > "appraise func=MODULE_CHECK appraise_flag=check_blacklist appraise_type=imasig|modsig" ) > or with CONFIG_MODULE_SIG_FORCE/module.sig_enforce=1. > > Sometimes this leads to arguably unexpected interactions - for example > commit fa4f3f56ccd2 ("powerpc/ima: Fix secure boot rules in ima arch > policy"), so it might be interesting to see if we can make things easier > to understand. I suspect that is the root of the problem here. Until distributions pick up IMA and properly document step by step in detail how to implement, enable, and debug it the _SIG options are required for users to be able to make use of signatures. The other part is that distributions apply 'lockdown' patches that change the security policy depending on secure boot status which were rejected by upstream which only hook into the _SIG options, and not into the IMA_ options. Of course, I expect this to change when the IMA options are universally available across architectures and the support picked up by distributions. Which brings the third point: IMA features vary across architectures, and KEXEC_SIG is more common than IMA_KEXEC. config/arm64/default:CONFIG_HAVE_IMA_KEXEC=y config/ppc64le/default:CONFIG_HAVE_IMA_KEXEC=y config/arm64/default:CONFIG_KEXEC_SIG=y config/s390x/default:CONFIG_KEXEC_SIG=y config/x86_64/default:CONFIG_KEXEC_SIG=y KEXEC_SIG makes it much easier to get uniform features across architectures. Thanks Michal
On 11/5/21 09:14, Michal Suchánek wrote: > On Fri, Nov 05, 2021 at 09:55:52PM +1100, Daniel Axtens wrote: >> Michal Suchanek <msuchanek@suse.de> writes: >> >>> S390 uses appended signature for kernel but implements the check >>> separately from module loader. >>> >>> Support for secure boot on powerpc with appended signature is planned - >>> grub patches submitted upstream but not yet merged. >> Power Non-Virtualised / OpenPower already supports secure boot via kexec >> with signature verification via IMA. I think you have now sent a >> follow-up series that merges some of the IMA implementation, I just >> wanted to make sure it was clear that we actually already have support > So is IMA_KEXEC and KEXEC_SIG redundant? > > I see some architectures have both. I also see there is a lot of overlap > between the IMA framework and the KEXEC_SIG and MODULE_SIg. Originally, KEXEC_SIG was meant for PECOFF based signatures, while IMA_KEXEC mainly supported xattr based signatures. Power (Non-virtualized/OpenPOWER) doesn't support PECOFF. Extended attributes based signature verification doesn't work with netboot. That's when appended signature support was added to IMA. Using IMA_KEXEC has the benefit of being able to enable both signature verification and measurement of the kernel image. Thanks & Regards, - Nayna
On 11/8/21 07:05, Michal Suchánek wrote: > Hello, > > On Mon, Nov 08, 2021 at 09:18:56AM +1100, Daniel Axtens wrote: >> Michal Suchánek <msuchanek@suse.de> writes: >> >>> On Fri, Nov 05, 2021 at 09:55:52PM +1100, Daniel Axtens wrote: >>>> Michal Suchanek <msuchanek@suse.de> writes: >>>> >>>>> S390 uses appended signature for kernel but implements the check >>>>> separately from module loader. >>>>> >>>>> Support for secure boot on powerpc with appended signature is planned - >>>>> grub patches submitted upstream but not yet merged. >>>> Power Non-Virtualised / OpenPower already supports secure boot via kexec >>>> with signature verification via IMA. I think you have now sent a >>>> follow-up series that merges some of the IMA implementation, I just >>>> wanted to make sure it was clear that we actually already have support >>> So is IMA_KEXEC and KEXEC_SIG redundant? >>> >>> I see some architectures have both. I also see there is a lot of overlap >>> between the IMA framework and the KEXEC_SIG and MODULE_SIg. >> >> Mimi would be much better placed than me to answer this. >> >> The limits of my knowledge are basically that signature verification for >> modules and kexec kernels can be enforced by IMA policies. >> >> For example a secure booted powerpc kernel with module support will have >> the following IMA policy set at the arch level: >> >> "appraise func=KEXEC_KERNEL_CHECK appraise_flag=check_blacklist appraise_type=imasig|modsig", >> (in arch/powerpc/kernel/ima_arch.c) >> >> Module signature enforcement can be set with either IMA (policy like >> "appraise func=MODULE_CHECK appraise_flag=check_blacklist appraise_type=imasig|modsig" ) >> or with CONFIG_MODULE_SIG_FORCE/module.sig_enforce=1. >> >> Sometimes this leads to arguably unexpected interactions - for example >> commit fa4f3f56ccd2 ("powerpc/ima: Fix secure boot rules in ima arch >> policy"), so it might be interesting to see if we can make things easier >> to understand. > I suspect that is the root of the problem here. Until distributions pick > up IMA and properly document step by step in detail how to implement, > enable, and debug it the _SIG options are required for users to be able > to make use of signatures. For secureboot, IMA appraisal policies are configured in kernel at boot time based on secureboot state of the system, refer arch/powerpc/kernel/ima_arch.c and security/integrity/ima/ima_efi.c. This doesn't require any user configuration. Yes, I agree it would be helpful to update kernel documentation specifying steps to sign the kernel image using sign-file. > > The other part is that distributions apply 'lockdown' patches that change > the security policy depending on secure boot status which were rejected > by upstream which only hook into the _SIG options, and not into the IMA_ > options. Of course, I expect this to change when the IMA options are > universally available across architectures and the support picked up by > distributions. > > Which brings the third point: IMA features vary across architectures, > and KEXEC_SIG is more common than IMA_KEXEC. > > config/arm64/default:CONFIG_HAVE_IMA_KEXEC=y > config/ppc64le/default:CONFIG_HAVE_IMA_KEXEC=y > > config/arm64/default:CONFIG_KEXEC_SIG=y > config/s390x/default:CONFIG_KEXEC_SIG=y > config/x86_64/default:CONFIG_KEXEC_SIG=y > > KEXEC_SIG makes it much easier to get uniform features across > architectures. Architectures use KEXEC_SIG vs IMA_KEXEC based on their requirement. IMA_KEXEC is for the kernel images signed using sign-file (appended signatures, not PECOFF), provides measurement along with verification, and is tied to secureboot state of the system at boot time. Thanks & Regards, - Nayna
Hello, On Thu, Nov 11, 2021 at 05:26:41PM -0500, Nayna wrote: > > On 11/8/21 07:05, Michal Suchánek wrote: > > Hello, > > > > On Mon, Nov 08, 2021 at 09:18:56AM +1100, Daniel Axtens wrote: > > > Michal Suchánek <msuchanek@suse.de> writes: > > > > > > > On Fri, Nov 05, 2021 at 09:55:52PM +1100, Daniel Axtens wrote: > > > > > Michal Suchanek <msuchanek@suse.de> writes: > > > > > > > > > > > S390 uses appended signature for kernel but implements the check > > > > > > separately from module loader. > > > > > > > > > > > > Support for secure boot on powerpc with appended signature is planned - > > > > > > grub patches submitted upstream but not yet merged. > > > > > Power Non-Virtualised / OpenPower already supports secure boot via kexec > > > > > with signature verification via IMA. I think you have now sent a > > > > > follow-up series that merges some of the IMA implementation, I just > > > > > wanted to make sure it was clear that we actually already have support > > > > So is IMA_KEXEC and KEXEC_SIG redundant? > > > > > > > > I see some architectures have both. I also see there is a lot of overlap > > > > between the IMA framework and the KEXEC_SIG and MODULE_SIg. > > > > > > Mimi would be much better placed than me to answer this. > > > > > > The limits of my knowledge are basically that signature verification for > > > modules and kexec kernels can be enforced by IMA policies. > > > > > > For example a secure booted powerpc kernel with module support will have > > > the following IMA policy set at the arch level: > > > > > > "appraise func=KEXEC_KERNEL_CHECK appraise_flag=check_blacklist appraise_type=imasig|modsig", > > > (in arch/powerpc/kernel/ima_arch.c) > > > > > > Module signature enforcement can be set with either IMA (policy like > > > "appraise func=MODULE_CHECK appraise_flag=check_blacklist appraise_type=imasig|modsig" ) > > > or with CONFIG_MODULE_SIG_FORCE/module.sig_enforce=1. > > > > > > Sometimes this leads to arguably unexpected interactions - for example > > > commit fa4f3f56ccd2 ("powerpc/ima: Fix secure boot rules in ima arch > > > policy"), so it might be interesting to see if we can make things easier > > > to understand. > > I suspect that is the root of the problem here. Until distributions pick > > up IMA and properly document step by step in detail how to implement, > > enable, and debug it the _SIG options are required for users to be able > > to make use of signatures. > > For secureboot, IMA appraisal policies are configured in kernel at boot time > based on secureboot state of the system, refer > arch/powerpc/kernel/ima_arch.c and security/integrity/ima/ima_efi.c. This > doesn't require any user configuration. Yes, I agree it would be helpful to > update kernel documentation specifying steps to sign the kernel image using > sign-file. > > > > > The other part is that distributions apply 'lockdown' patches that change > > the security policy depending on secure boot status which were rejected > > by upstream which only hook into the _SIG options, and not into the IMA_ > > options. Of course, I expect this to change when the IMA options are > > universally available across architectures and the support picked up by > > distributions. > > > > Which brings the third point: IMA features vary across architectures, > > and KEXEC_SIG is more common than IMA_KEXEC. > > > > config/arm64/default:CONFIG_HAVE_IMA_KEXEC=y > > config/ppc64le/default:CONFIG_HAVE_IMA_KEXEC=y > > > > config/arm64/default:CONFIG_KEXEC_SIG=y > > config/s390x/default:CONFIG_KEXEC_SIG=y > > config/x86_64/default:CONFIG_KEXEC_SIG=y > > > > KEXEC_SIG makes it much easier to get uniform features across > > architectures. > > Architectures use KEXEC_SIG vs IMA_KEXEC based on their requirement. > IMA_KEXEC is for the kernel images signed using sign-file (appended > signatures, not PECOFF), provides measurement along with verification, and That's certainly not the case. S390 uses appended signatures with KEXEC_SIG, arm64 uses PECOFF with both KEXEC_SIG and IMA_KEXEC. > is tied to secureboot state of the system at boot time. In distrubutions it's also the case with KEXEC_SIG, it's only upstream where this is different. I don't know why Linux upstream has rejected this support for KEXEC_SIG. Anyway, sounds like the difference is that IMA provides measurement but if you don't use it it does not makes any difference except more comlex code. Thanks Michal
On 11/12/21 03:30, Michal Suchánek wrote: > Hello, > > On Thu, Nov 11, 2021 at 05:26:41PM -0500, Nayna wrote: >> On 11/8/21 07:05, Michal Suchánek wrote: >>> Hello, >>> >>> On Mon, Nov 08, 2021 at 09:18:56AM +1100, Daniel Axtens wrote: >>>> Michal Suchánek <msuchanek@suse.de> writes: >>>> >>>>> On Fri, Nov 05, 2021 at 09:55:52PM +1100, Daniel Axtens wrote: >>>>>> Michal Suchanek <msuchanek@suse.de> writes: >>>>>> >>>>>>> S390 uses appended signature for kernel but implements the check >>>>>>> separately from module loader. >>>>>>> >>>>>>> Support for secure boot on powerpc with appended signature is planned - >>>>>>> grub patches submitted upstream but not yet merged. >>>>>> Power Non-Virtualised / OpenPower already supports secure boot via kexec >>>>>> with signature verification via IMA. I think you have now sent a >>>>>> follow-up series that merges some of the IMA implementation, I just >>>>>> wanted to make sure it was clear that we actually already have support >>>>> So is IMA_KEXEC and KEXEC_SIG redundant? >>>>> >>>>> I see some architectures have both. I also see there is a lot of overlap >>>>> between the IMA framework and the KEXEC_SIG and MODULE_SIg. >>>> Mimi would be much better placed than me to answer this. >>>> >>>> The limits of my knowledge are basically that signature verification for >>>> modules and kexec kernels can be enforced by IMA policies. >>>> >>>> For example a secure booted powerpc kernel with module support will have >>>> the following IMA policy set at the arch level: >>>> >>>> "appraise func=KEXEC_KERNEL_CHECK appraise_flag=check_blacklist appraise_type=imasig|modsig", >>>> (in arch/powerpc/kernel/ima_arch.c) >>>> >>>> Module signature enforcement can be set with either IMA (policy like >>>> "appraise func=MODULE_CHECK appraise_flag=check_blacklist appraise_type=imasig|modsig" ) >>>> or with CONFIG_MODULE_SIG_FORCE/module.sig_enforce=1. >>>> >>>> Sometimes this leads to arguably unexpected interactions - for example >>>> commit fa4f3f56ccd2 ("powerpc/ima: Fix secure boot rules in ima arch >>>> policy"), so it might be interesting to see if we can make things easier >>>> to understand. >>> I suspect that is the root of the problem here. Until distributions pick >>> up IMA and properly document step by step in detail how to implement, >>> enable, and debug it the _SIG options are required for users to be able >>> to make use of signatures. >> For secureboot, IMA appraisal policies are configured in kernel at boot time >> based on secureboot state of the system, refer >> arch/powerpc/kernel/ima_arch.c and security/integrity/ima/ima_efi.c. This >> doesn't require any user configuration. Yes, I agree it would be helpful to >> update kernel documentation specifying steps to sign the kernel image using >> sign-file. >> >>> The other part is that distributions apply 'lockdown' patches that change >>> the security policy depending on secure boot status which were rejected >>> by upstream which only hook into the _SIG options, and not into the IMA_ >>> options. Of course, I expect this to change when the IMA options are >>> universally available across architectures and the support picked up by >>> distributions. >>> >>> Which brings the third point: IMA features vary across architectures, >>> and KEXEC_SIG is more common than IMA_KEXEC. >>> >>> config/arm64/default:CONFIG_HAVE_IMA_KEXEC=y >>> config/ppc64le/default:CONFIG_HAVE_IMA_KEXEC=y >>> >>> config/arm64/default:CONFIG_KEXEC_SIG=y >>> config/s390x/default:CONFIG_KEXEC_SIG=y >>> config/x86_64/default:CONFIG_KEXEC_SIG=y >>> >>> KEXEC_SIG makes it much easier to get uniform features across >>> architectures. >> Architectures use KEXEC_SIG vs IMA_KEXEC based on their requirement. >> IMA_KEXEC is for the kernel images signed using sign-file (appended >> signatures, not PECOFF), provides measurement along with verification, and > That's certainly not the case. S390 uses appended signatures with > KEXEC_SIG, arm64 uses PECOFF with both KEXEC_SIG and IMA_KEXEC. Yes, S390 uses appended signature, but they also do not support measurements. On the other hand for arm64/x86, PECOFF works only with KEXEC_SIG. Look at the KEXEC_IMAGE_VERIFY_SIG config dependencies in arch/arm64/Kconfig and KEXEC_BZIMAGE_VERIFY_SIG config dependencies in arch/x86/Kconfig. Now, if KEXEC_SIG is not enabled, then IMA appraisal policies are enforced if secure boot is enabled, refer to security/integrity/ima_efi.c . IMA would fail verification if kernel is not signed with module sig appended signatures or signature verification fails. In short, IMA is used to enforce the existence of a policy if secure boot is enabled. If they don't support module sig appended signatures, by definition it fails. Thus PECOFF doesn't work with both KEXEC_SIG and IMA_KEXEC, but only with KEXEC_SIG. Lakshmi, do you agree with my reasoning ? > >> is tied to secureboot state of the system at boot time. > In distrubutions it's also the case with KEXEC_SIG, it's only upstream > where this is different. I don't know why Linux upstream has rejected > this support for KEXEC_SIG. > > Anyway, sounds like the difference is that IMA provides measurement but > if you don't use it it does not makes any difference except more comlex > code. I am unsure what do you mean by "complex code" here. Can you please elaborate ? IMA policies support for secureboot already exists and can be used as it is without adding any extra work as in arch/powerpc/kernel/ima_arch.c. Also, if my analysis is right, I think I understand arm64/x86 support for both KEXEC_SIG and IMA_KEXEC as it can support two signature formats - PECOFF/module sig appended signature. I am not clear from the patch descriptions on the need to add KEXEC_SIG support on POWER when that will also be based on module sig appended signatures like IMA_KEXEC. Thanks & Regards, - Nayna
On Mon, Nov 15, 2021 at 06:53:53PM -0500, Nayna wrote: > > On 11/12/21 03:30, Michal Suchánek wrote: > > Hello, > > > > On Thu, Nov 11, 2021 at 05:26:41PM -0500, Nayna wrote: > > > On 11/8/21 07:05, Michal Suchánek wrote: > > > > Hello, > > > > > > > > The other part is that distributions apply 'lockdown' patches that change > > > > the security policy depending on secure boot status which were rejected > > > > by upstream which only hook into the _SIG options, and not into the IMA_ > > > > options. Of course, I expect this to change when the IMA options are > > > > universally available across architectures and the support picked up by > > > > distributions. > > > > > > > > Which brings the third point: IMA features vary across architectures, > > > > and KEXEC_SIG is more common than IMA_KEXEC. > > > > > > > > config/arm64/default:CONFIG_HAVE_IMA_KEXEC=y > > > > config/ppc64le/default:CONFIG_HAVE_IMA_KEXEC=y > > > > > > > > config/arm64/default:CONFIG_KEXEC_SIG=y > > > > config/s390x/default:CONFIG_KEXEC_SIG=y > > > > config/x86_64/default:CONFIG_KEXEC_SIG=y > > > > > > > > KEXEC_SIG makes it much easier to get uniform features across > > > > architectures. > > > Architectures use KEXEC_SIG vs IMA_KEXEC based on their requirement. > > > IMA_KEXEC is for the kernel images signed using sign-file (appended > > > signatures, not PECOFF), provides measurement along with verification, and > > That's certainly not the case. S390 uses appended signatures with > > KEXEC_SIG, arm64 uses PECOFF with both KEXEC_SIG and IMA_KEXEC. > > Yes, S390 uses appended signature, but they also do not support > measurements. > > On the other hand for arm64/x86, PECOFF works only with KEXEC_SIG. Look at > the KEXEC_IMAGE_VERIFY_SIG config dependencies in arch/arm64/Kconfig and > KEXEC_BZIMAGE_VERIFY_SIG config dependencies in arch/x86/Kconfig. Now, if > KEXEC_SIG is not enabled, then IMA appraisal policies are enforced if secure > boot is enabled, refer to security/integrity/ima_efi.c . IMA would fail > verification if kernel is not signed with module sig appended signatures or > signature verification fails. > > In short, IMA is used to enforce the existence of a policy if secure boot is > enabled. If they don't support module sig appended signatures, by definition > it fails. Thus PECOFF doesn't work with both KEXEC_SIG and IMA_KEXEC, but > only with KEXEC_SIG. Then IMA_KEXEC is a no-go. It is not supported on all architectures and it principially cannot be supported because it does not support PECOFF which is needed to boot the kernel on EFI platforms. To get feature parity across architectures KEXEC_SIG is required. > > > > > is tied to secureboot state of the system at boot time. > > In distrubutions it's also the case with KEXEC_SIG, it's only upstream > > where this is different. I don't know why Linux upstream has rejected > > this support for KEXEC_SIG. > > > > Anyway, sounds like the difference is that IMA provides measurement but > > if you don't use it it does not makes any difference except more comlex > > code. > I am unsure what do you mean by "complex code" here. Can you please > elaborate ? IMA policies support for secureboot already exists and can be > used as it is without adding any extra work as in > arch/powerpc/kernel/ima_arch.c. The code exists but using it to replace KEXEC_SIG also requires understanding the code and the implications of using it. At a glance the IMA codebase is much bigger and more convoluted compared to KEXEC_SIG and MODULE_SIG. Thanks Michal
On 11/16/21 04:53, Michal Suchánek wrote: > On Mon, Nov 15, 2021 at 06:53:53PM -0500, Nayna wrote: >> On 11/12/21 03:30, Michal Suchánek wrote: >>> Hello, >>> >>> On Thu, Nov 11, 2021 at 05:26:41PM -0500, Nayna wrote: >>>> On 11/8/21 07:05, Michal Suchánek wrote: >>>>> Hello, >>>>> >>>>> The other part is that distributions apply 'lockdown' patches that change >>>>> the security policy depending on secure boot status which were rejected >>>>> by upstream which only hook into the _SIG options, and not into the IMA_ >>>>> options. Of course, I expect this to change when the IMA options are >>>>> universally available across architectures and the support picked up by >>>>> distributions. >>>>> >>>>> Which brings the third point: IMA features vary across architectures, >>>>> and KEXEC_SIG is more common than IMA_KEXEC. >>>>> >>>>> config/arm64/default:CONFIG_HAVE_IMA_KEXEC=y >>>>> config/ppc64le/default:CONFIG_HAVE_IMA_KEXEC=y >>>>> >>>>> config/arm64/default:CONFIG_KEXEC_SIG=y >>>>> config/s390x/default:CONFIG_KEXEC_SIG=y >>>>> config/x86_64/default:CONFIG_KEXEC_SIG=y >>>>> >>>>> KEXEC_SIG makes it much easier to get uniform features across >>>>> architectures. >>>> Architectures use KEXEC_SIG vs IMA_KEXEC based on their requirement. >>>> IMA_KEXEC is for the kernel images signed using sign-file (appended >>>> signatures, not PECOFF), provides measurement along with verification, and >>> That's certainly not the case. S390 uses appended signatures with >>> KEXEC_SIG, arm64 uses PECOFF with both KEXEC_SIG and IMA_KEXEC. >> Yes, S390 uses appended signature, but they also do not support >> measurements. >> >> On the other hand for arm64/x86, PECOFF works only with KEXEC_SIG. Look at >> the KEXEC_IMAGE_VERIFY_SIG config dependencies in arch/arm64/Kconfig and >> KEXEC_BZIMAGE_VERIFY_SIG config dependencies in arch/x86/Kconfig. Now, if >> KEXEC_SIG is not enabled, then IMA appraisal policies are enforced if secure >> boot is enabled, refer to security/integrity/ima_efi.c . IMA would fail >> verification if kernel is not signed with module sig appended signatures or >> signature verification fails. >> >> In short, IMA is used to enforce the existence of a policy if secure boot is >> enabled. If they don't support module sig appended signatures, by definition >> it fails. Thus PECOFF doesn't work with both KEXEC_SIG and IMA_KEXEC, but >> only with KEXEC_SIG. > Then IMA_KEXEC is a no-go. It is not supported on all architectures and > it principially cannot be supported because it does not support PECOFF > which is needed to boot the kernel on EFI platforms. To get feature > parity across architectures KEXEC_SIG is required. I would not say "a no-go", it is based on user requirements. The key takeaway from this discussion is that both KEXEC_SIG and IMA_KEXEC support functionality with some small degree of overlap, and that documenting the differences is needed. This will help kernel consumers to understand the difference and enable the appropriate functionality for their environment. As per my understanding: KEXEC_SIG: * Supports kernel image verification * Linked with secureboot state using downstream patch * Supports PECOFF and module sig appended signature format * Supports blocklisting of keys IMA_KEXEC: * Supports kernel image verification * Linked with secureboot state in upstream * Supports module sig appended signature format and signatures in extended attribute. * Supports blocklisting of keys * Supports blocklisting single kernel binary * Supports measurements for attestation * Supports audit log Users can enable the option based on their requirements. Thanks for the good discussion and enabling KEXEC_SIG for POWER as well. It would be good to have updated kernel documentation to go along with KEXEC_SIG support in the patchset. Thanks & Regards, - Nayna
Hello, On Thu, Nov 18, 2021 at 05:34:01PM -0500, Nayna wrote: > > On 11/16/21 04:53, Michal Suchánek wrote: > > On Mon, Nov 15, 2021 at 06:53:53PM -0500, Nayna wrote: > > > On 11/12/21 03:30, Michal Suchánek wrote: > > > > Hello, > > > > > > > > On Thu, Nov 11, 2021 at 05:26:41PM -0500, Nayna wrote: > > > > > On 11/8/21 07:05, Michal Suchánek wrote: > > > > > > Hello, > > > > > > > > > > > > The other part is that distributions apply 'lockdown' patches that change > > > > > > the security policy depending on secure boot status which were rejected > > > > > > by upstream which only hook into the _SIG options, and not into the IMA_ > > > > > > options. Of course, I expect this to change when the IMA options are > > > > > > universally available across architectures and the support picked up by > > > > > > distributions. > > > > > > > > > > > > Which brings the third point: IMA features vary across architectures, > > > > > > and KEXEC_SIG is more common than IMA_KEXEC. > > > > > > > > > > > > config/arm64/default:CONFIG_HAVE_IMA_KEXEC=y > > > > > > config/ppc64le/default:CONFIG_HAVE_IMA_KEXEC=y > > > > > > > > > > > > config/arm64/default:CONFIG_KEXEC_SIG=y > > > > > > config/s390x/default:CONFIG_KEXEC_SIG=y > > > > > > config/x86_64/default:CONFIG_KEXEC_SIG=y > > > > > > > > > > > > KEXEC_SIG makes it much easier to get uniform features across > > > > > > architectures. > > > > > Architectures use KEXEC_SIG vs IMA_KEXEC based on their requirement. > > > > > IMA_KEXEC is for the kernel images signed using sign-file (appended > > > > > signatures, not PECOFF), provides measurement along with verification, and > > > > That's certainly not the case. S390 uses appended signatures with > > > > KEXEC_SIG, arm64 uses PECOFF with both KEXEC_SIG and IMA_KEXEC. > > > Yes, S390 uses appended signature, but they also do not support > > > measurements. > > > > > > On the other hand for arm64/x86, PECOFF works only with KEXEC_SIG. Look at > > > the KEXEC_IMAGE_VERIFY_SIG config dependencies in arch/arm64/Kconfig and > > > KEXEC_BZIMAGE_VERIFY_SIG config dependencies in arch/x86/Kconfig. Now, if > > > KEXEC_SIG is not enabled, then IMA appraisal policies are enforced if secure > > > boot is enabled, refer to security/integrity/ima_efi.c . IMA would fail > > > verification if kernel is not signed with module sig appended signatures or > > > signature verification fails. > > > > > > In short, IMA is used to enforce the existence of a policy if secure boot is > > > enabled. If they don't support module sig appended signatures, by definition > > > it fails. Thus PECOFF doesn't work with both KEXEC_SIG and IMA_KEXEC, but > > > only with KEXEC_SIG. > > Then IMA_KEXEC is a no-go. It is not supported on all architectures and > > it principially cannot be supported because it does not support PECOFF > > which is needed to boot the kernel on EFI platforms. To get feature > > parity across architectures KEXEC_SIG is required. > > I would not say "a no-go", it is based on user requirements. > > The key takeaway from this discussion is that both KEXEC_SIG and IMA_KEXEC > support functionality with some small degree of overlap, and that > documenting the differences is needed. This will help kernel consumers to > understand the difference and enable the appropriate functionality for their > environment. Maybe I was not clear enough. If you happen to focus on an architecture that supports IMA fully it's great. My point of view is maintaining multiple architectures. Both end users and people conecerend with security are rarely familiar with architecture specifics. Portability of documentation and debugging instructions across architectures is a concern. IMA has large number of options with varying availablitily across architectures for no apparent reason. The situation is complex and hard to grasp. In comparison the *_SIG options are widely available. The missing support for KEXEC_SIG on POWER is trivial to add by cut&paste from s390. With that all the documentation that exists already is also trivially applicable to POWER. Any additional code cleanup is a bonus but not really needed to enable the kexec lockdown on POWER. Thanks Michal
On Fri, 2021-11-19 at 12:18 +0100, Michal Suchánek wrote: > Maybe I was not clear enough. If you happen to focus on an architecture > that supports IMA fully it's great. > > My point of view is maintaining multiple architectures. Both end users > and people conecerend with security are rarely familiar with > architecture specifics. Portability of documentation and debugging > instructions across architectures is a concern. > > IMA has large number of options with varying availablitily across > architectures for no apparent reason. The situation is complex and hard > to grasp. IMA measures, verifies, and audits the integrity of files based on a system wide policy. The known "good" integrity value may be stored in the security.ima xattr or more recently as an appended signature. With both IMA kexec appraise and measurement policy rules, not only is the kernel image signature verified and the file hash included in the IMA measurement list, but the signature used to verify the integrity of the kexec kernel image is also included in the IMA measurement list (ima_template=ima-sig). Even without PECOFF support in IMA, IMA kexec measurement policy rules can be defined to supplement the KEXEC_SIG signature verfication. > > In comparison the *_SIG options are widely available. The missing > support for KEXEC_SIG on POWER is trivial to add by cut&paste from s390. > With that all the documentation that exists already is also trivially > applicable to POWER. Any additional code cleanup is a bonus but not > really needed to enable the kexec lockdown on POWER. Before lockdown was upstreamed, Matthew made sure that IMA signature verification could co-exist. Refer to commit 29d3c1c8dfe7 ("kexec: Allow kexec_file() with appropriate IMA policy when locked down"). If there is a problem with the downstream kexec lockdown patches, they should be fixed. The kexec kselftest might provide some insight into how the different signature verification methods and lockdown co-exist. As for adding KEXEC_SIG appended signature support on PowerPC based on the s390 code, it sounds reasonable. thanks, Mimi
Hi Mimi, On Fri, 19 Nov 2021 13:16:20 -0500 Mimi Zohar <zohar@linux.ibm.com> wrote: > On Fri, 2021-11-19 at 12:18 +0100, Michal Suchánek wrote: > > Maybe I was not clear enough. If you happen to focus on an architecture > > that supports IMA fully it's great. > > > > My point of view is maintaining multiple architectures. Both end users > > and people conecerend with security are rarely familiar with > > architecture specifics. Portability of documentation and debugging > > instructions across architectures is a concern. > > > > IMA has large number of options with varying availablitily across > > architectures for no apparent reason. The situation is complex and hard > > to grasp. > > IMA measures, verifies, and audits the integrity of files based on a > system wide policy. The known "good" integrity value may be stored in > the security.ima xattr or more recently as an appended signature. > > With both IMA kexec appraise and measurement policy rules, not only is > the kernel image signature verified and the file hash included in the > IMA measurement list, but the signature used to verify the integrity of > the kexec kernel image is also included in the IMA measurement list > (ima_template=ima-sig). > > Even without PECOFF support in IMA, IMA kexec measurement policy rules > can be defined to supplement the KEXEC_SIG signature verfication. > > > In comparison the *_SIG options are widely available. The missing > > support for KEXEC_SIG on POWER is trivial to add by cut&paste from s390. > > With that all the documentation that exists already is also trivially > > applicable to POWER. Any additional code cleanup is a bonus but not > > really needed to enable the kexec lockdown on POWER. > > Before lockdown was upstreamed, Matthew made sure that IMA signature > verification could co-exist. Refer to commit 29d3c1c8dfe7 ("kexec: > Allow kexec_file() with appropriate IMA policy when locked down"). If > there is a problem with the downstream kexec lockdown patches, they > should be fixed. > > The kexec kselftest might provide some insight into how the different > signature verification methods and lockdown co-exist. > > As for adding KEXEC_SIG appended signature support on PowerPC based on > the s390 code, it sounds reasonable. Heiko contacted me as you apparently requested that someone from s390 takes part in this discussion. I now spend over a day trying to make any sens from this discussion but failed. The way I see it is. On one hand there is KEXEC_SIG which is specifically designed to verify the signatures of kernel images in kexec_file_load. From the beginning it was designed in a way that every architecture (in fact even every image type) can define its own callback function as needed. It's design is simple and easy to extend and thus was adopted by all architectures, except ppc, so far. On the other hand there is IMA which is much more general and also includes the same functionality like KEXEC_SIG but only on some architectures in some special cases and without proper documentation. Now Michal wants to adapt KEXEC_SIG for ppc too so distros can rely on all architectures using the same mechanism and thus reduce maintenance cost. On the way there he even makes some absolutely reasonable improvements for everybody. Why is that so controversial? What is the real problem that should be discussed here? Thanks Philipp
On Wed, 2021-11-24 at 12:09 +0100, Philipp Rudo wrote: > Now Michal wants to adapt KEXEC_SIG for ppc too so distros can rely on all > architectures using the same mechanism and thus reduce maintenance cost. > On the way there he even makes some absolutely reasonable improvements > for everybody. > > Why is that so controversial? What is the real problem that should be > discussed here? Nothing is controversial with what Michal wants to do. I've already said, "As for adding KEXEC_SIG appended signature support on PowerPC based on the s390 code, it sounds reasonable." thanks, Mimi
On Wed, Nov 24, 2021 at 08:10:10AM -0500, Mimi Zohar wrote: > On Wed, 2021-11-24 at 12:09 +0100, Philipp Rudo wrote: > > Now Michal wants to adapt KEXEC_SIG for ppc too so distros can rely on all > > architectures using the same mechanism and thus reduce maintenance cost. > > On the way there he even makes some absolutely reasonable improvements > > for everybody. > > > > Why is that so controversial? What is the real problem that should be > > discussed here? > > Nothing is controversial with what Michal wants to do. I've already > said, "As for adding KEXEC_SIG appended signature support on PowerPC > based on the s390 code, it sounds reasonable." Ok, I will resend the series with the arch-specific changes first to be independent of the core cleanup. Thanks Michal
Hi Michal, On Wed, 24 Nov 2021 14:27:16 +0100 Michal Suchánek <msuchanek@suse.de> wrote: > On Wed, Nov 24, 2021 at 08:10:10AM -0500, Mimi Zohar wrote: > > On Wed, 2021-11-24 at 12:09 +0100, Philipp Rudo wrote: > > > Now Michal wants to adapt KEXEC_SIG for ppc too so distros can rely on all > > > architectures using the same mechanism and thus reduce maintenance cost. > > > On the way there he even makes some absolutely reasonable improvements > > > for everybody. > > > > > > Why is that so controversial? What is the real problem that should be > > > discussed here? > > > > Nothing is controversial with what Michal wants to do. I've already > > said, "As for adding KEXEC_SIG appended signature support on PowerPC > > based on the s390 code, it sounds reasonable." > > Ok, I will resend the series with the arch-specific changes first to be > independent of the core cleanup. could you please add the kexec@lists.infradead.org to Cc when you resend the series. As this is kexec related I think it makes sense to give them a heads up, too. Thanks Philipp