linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nayna <nayna@linux.vnet.ibm.com>
To: "Michal Suchánek" <msuchanek@suse.de>
Cc: Mimi Zohar <zohar@linux.ibm.com>,
	keyrings@vger.kernel.org, Rob Herring <robh@kernel.org>,
	linux-s390@vger.kernel.org, Vasily Gorbik <gor@linux.ibm.com>,
	Lakshmi Ramasubramanian <nramas@linux.microsoft.com>,
	Heiko Carstens <hca@linux.ibm.com>, Jessica Yu <jeyu@kernel.org>,
	linux-kernel@vger.kernel.org, David Howells <dhowells@redhat.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Paul Mackerras <paulus@samba.org>,
	Hari Bathini <hbathini@linux.ibm.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	linuxppc-dev@lists.ozlabs.org,
	Frank van der Linden <fllinden@amazon.com>,
	Thiago Jung Bauermann <bauerman@linux.ibm.com>,
	Daniel Axtens <dja@axtens.net>,
	buendgen@de.ibm.com
Subject: Re: [PATCH 0/3] KEXEC_SIG with appended signature
Date: Mon, 15 Nov 2021 18:53:53 -0500	[thread overview]
Message-ID: <8cd90fea-05c9-b5f9-5e0c-84f98b2f55cd@linux.vnet.ibm.com> (raw)
In-Reply-To: <20211112083055.GA34414@kunlun.suse.cz>


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


  reply	other threads:[~2021-11-16  0:16 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-03 14:27 [PATCH 0/3] KEXEC_SIG with appended signature Michal Suchanek
2021-11-03 14:27 ` [PATCH 1/3] s390/kexec_file: Don't opencode appended signature verification Michal Suchanek
2021-11-03 14:27 ` [PATCH 2/3] module: strip the signature marker in the verification function Michal Suchanek
2021-11-03 14:27 ` [PATCH 3/3] powerpc/kexec_file: Add KEXEC_SIG support Michal Suchanek
2021-11-05  9:55 ` [PATCH 0/2] Additional appended signature cleanup Michal Suchanek
2021-11-05  9:55   ` [PATCH 1/2] module: Use key_being_used_for for log messages in verify_appended_signature Michal Suchanek
2021-11-05  9:55   ` [PATCH 2/2] module: Move duplicate mod_check_sig users code to mod_parse_sig Michal Suchanek
2021-11-05 10:55 ` [PATCH 0/3] KEXEC_SIG with appended signature Daniel Axtens
2021-11-05 13:14   ` Michal Suchánek
2021-11-07 22:18     ` Daniel Axtens
2021-11-08 12:05       ` Michal Suchánek
2021-11-11 22:26         ` Nayna
2021-11-12  8:30           ` Michal Suchánek
2021-11-15 23:53             ` Nayna [this message]
2021-11-16  9:53               ` Michal Suchánek
2021-11-18 22:34                 ` Nayna
2021-11-19 11:18                   ` Michal Suchánek
2021-11-19 18:16                     ` Mimi Zohar
2021-11-24 11:09                       ` Philipp Rudo
2021-11-24 13:10                         ` Mimi Zohar
2021-11-24 13:27                           ` Michal Suchánek
2021-11-25  9:14                             ` Philipp Rudo
2021-11-11 22:23     ` Nayna

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8cd90fea-05c9-b5f9-5e0c-84f98b2f55cd@linux.vnet.ibm.com \
    --to=nayna@linux.vnet.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=bauerman@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=buendgen@de.ibm.com \
    --cc=dhowells@redhat.com \
    --cc=dja@axtens.net \
    --cc=fllinden@amazon.com \
    --cc=gor@linux.ibm.com \
    --cc=hbathini@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=jeyu@kernel.org \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mcgrof@kernel.org \
    --cc=msuchanek@suse.de \
    --cc=nramas@linux.microsoft.com \
    --cc=paulus@samba.org \
    --cc=robh@kernel.org \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).