From: "Michal Suchánek" <msuchanek@suse.de>
To: Nayna <nayna@linux.vnet.ibm.com>
Cc: Thiago Jung Bauermann <bauerman@linux.ibm.com>,
Rob Herring <robh@kernel.org>, Vasily Gorbik <gor@linux.ibm.com>,
linux-s390@vger.kernel.org, Heiko Carstens <hca@linux.ibm.com>,
linux-kernel@vger.kernel.org, Mimi Zohar <zohar@linux.ibm.com>,
David Howells <dhowells@redhat.com>,
Lakshmi Ramasubramanian <nramas@linux.microsoft.com>,
Luis Chamberlain <mcgrof@kernel.org>,
keyrings@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
Frank van der Linden <fllinden@amazon.com>,
Jessica Yu <jeyu@kernel.org>,
Alexander Gordeev <agordeev@linux.ibm.com>,
buendgen@de.ibm.com, linuxppc-dev@lists.ozlabs.org,
Christian Borntraeger <borntraeger@de.ibm.com>,
Hari Bathini <hbathini@linux.ibm.com>,
Daniel Axtens <dja@axtens.net>
Subject: Re: [PATCH 0/3] KEXEC_SIG with appended signature
Date: Tue, 16 Nov 2021 10:53:43 +0100 [thread overview]
Message-ID: <20211116095343.GG34414@kunlun.suse.cz> (raw)
In-Reply-To: <8cd90fea-05c9-b5f9-5e0c-84f98b2f55cd@linux.vnet.ibm.com>
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
next prev parent reply other threads:[~2021-11-16 9:54 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
2021-11-16 9:53 ` Michal Suchánek [this message]
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=20211116095343.GG34414@kunlun.suse.cz \
--to=msuchanek@suse.de \
--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=nayna@linux.vnet.ibm.com \
--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).