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@xxxxxxx> writes:
On Fri, Nov 05, 2021 at 09:55:52PM +1100, Daniel Axtens wrote:
Michal Suchanek <msuchanek@xxxxxxx> 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
