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>,
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: Fri, 12 Nov 2021 09:30:55 +0100 [thread overview]
Message-ID: <20211112083055.GA34414@kunlun.suse.cz> (raw)
In-Reply-To: <56d2ae87-b9bf-c9fc-1395-db4769a424ea@linux.vnet.ibm.com>
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
next prev parent reply other threads:[~2021-11-12 8:31 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 [this message]
2021-11-15 23:53 ` Nayna
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=20211112083055.GA34414@kunlun.suse.cz \
--to=msuchanek@suse.de \
--cc=agordeev@linux.ibm.com \
--cc=bauerman@linux.ibm.com \
--cc=borntraeger@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).