Messages in this thread | | | Date | Thu, 11 Nov 2021 17:26:41 -0500 | Subject | Re: [PATCH 0/3] KEXEC_SIG with appended signature | From | 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
| |