All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: "Michal Suchánek" <msuchanek@suse.de>,
	"Paul Menzel" <pmenzel@molgen.mpg.de>
Cc: keyrings@vger.kernel.org, linux-crypto@vger.kernel.org,
	linux-integrity@vger.kernel.org, kexec@lists.infradead.org,
	Philipp Rudo <prudo@redhat.com>, Nayna <nayna@linux.vnet.ibm.com>,
	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, Michael Ellerman <mpe@ellerman.id.au>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
	James Morris <jmorris@namei.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	Sven Schnelle <svens@linux.ibm.com>, Baoquan He <bhe@redhat.com>,
	linux-security-module@vger.kernel.org
Subject: Re: [PATCH v5 2/6] powerpc/kexec_file: Add KEXEC_SIG support.
Date: Sun, 13 Feb 2022 12:50:31 -0500	[thread overview]
Message-ID: <b49cb41873655f4fc1269faab5729111d55ce9da.camel@linux.ibm.com> (raw)
In-Reply-To: <20220209120154.GC3113@kunlun.suse.cz>

Hi Michal,

On Wed, 2022-02-09 at 13:01 +0100, Michal Suchánek wrote:
> > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > > index dea74d7717c0..1cde9b6c5987 100644
> > > --- a/arch/powerpc/Kconfig
> > > +++ b/arch/powerpc/Kconfig
> > > @@ -560,6 +560,22 @@ config KEXEC_FILE
> > >   config ARCH_HAS_KEXEC_PURGATORY
> > >     def_bool KEXEC_FILE
> > > +config KEXEC_SIG
> > > +   bool "Verify kernel signature during kexec_file_load() syscall"
> > > +   depends on KEXEC_FILE && MODULE_SIG_FORMAT
> > > +   help
> > > +     This option makes kernel signature verification mandatory for
> > > +     the kexec_file_load() syscall.
> > > +
> > > +     In addition to that option, you need to enable signature
> > > +     verification for the corresponding kernel image type being
> > > +     loaded in order for this to work.
> > > +
> > > +     Note: on powerpc IMA_ARCH_POLICY also implements kexec'ed kernel
> > > +     verification. In addition IMA adds kernel hashes to the measurement
> > > +     list, extends IMA PCR in the TPM, and implements kernel image
> > > +     blacklist by hash.
> > 
> > So, what is the takeaway for the user? IMA_ARCH_POLICY is preferred? What is
> > the disadvantage, and two implementations(?) needed then? More overhead?
> 
> IMA_KEXEC does more than KEXEC_SIG. The overhead is probably not big
> unless you are trying to really minimize the kernel code size.
> 
> Arguably the simpler implementation hass less potential for bugs, too.
> Both in code and in user configuration required to enable the feature.
> 
> Interestingly IMA_ARCH_POLICY depends on KEXEC_SIG rather than
> IMA_KEXEC. Just mind-boggling.

FYI, a soft boot doesn't clear the TPM PCRs.  To be able to verify the
IMA measurement list after a kexec against a TPM quote, requires
carrying the measurement list across kexec.

The "IMA_KEXEC" config enables carrying the IMA measurement list across
kexec.  It has nothing to do with verifying the appended signature. 
That is based on kernel module appended signature code.

> 
> The main problem with IMA_KEXEC from my point of view is it is not portable.
> To record the measurements TPM support is requireed which is not available on
> all platforms.

Measuring the kexec kernel image and extending the TPM with the
measurement is required for trusted boot.  Boot loaders extend the
TPM's BIOS measurements. Similarly, IMA does not require a TPM, but if
one is available the kexec kernel image measurement is extended into
the IMA measurement list.  Otherwise, IMA goes into "TPM by-pass" mode.

> It does not support PE so it cannot be used on platforms
> that use PE kernel signature format.

True.  However, a kernel image with an appended signature may be
kexec'ed, regardless of the architecture.  Because some boot loaders
don't support appended signatures, from my point of view does not make
IMA kexec support not portable.

-- 
thanks,

Mimi


WARNING: multiple messages have this Message-ID (diff)
From: Mimi Zohar <zohar@linux.ibm.com>
To: "Michal Suchánek" <msuchanek@suse.de>,
	"Paul Menzel" <pmenzel@molgen.mpg.de>
Cc: Nayna <nayna@linux.vnet.ibm.com>,
	Sven Schnelle <svens@linux.ibm.com>,
	David Howells <dhowells@redhat.com>,
	keyrings@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Rob Herring <robh@kernel.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Baoquan He <bhe@redhat.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	James Morris <jmorris@namei.org>,
	Lakshmi Ramasubramanian <nramas@linux.microsoft.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	linux-s390@vger.kernel.org, Heiko Carstens <hca@linux.ibm.com>,
	Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
	Hari Bathini <hbathini@linux.ibm.com>,
	Daniel Axtens <dja@axtens.net>, Philipp Rudo <prudo@redhat.com>,
	Frank van der Linden <fllinden@amazon.com>,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	Luis Chamberlain <mcgrof@kernel.org>,
	linux-crypto@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	Jessica Yu <jeyu@kernel.org>,
	linux-integrity@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	"David S. Miller" <davem@davemloft.net>,
	Thiago Jung Bauermann <bauerman@linux.ibm.com>,
	buendgen@de.ibm.com
Subject: Re: [PATCH v5 2/6] powerpc/kexec_file: Add KEXEC_SIG support.
Date: Sun, 13 Feb 2022 12:50:31 -0500	[thread overview]
Message-ID: <b49cb41873655f4fc1269faab5729111d55ce9da.camel@linux.ibm.com> (raw)
In-Reply-To: <20220209120154.GC3113@kunlun.suse.cz>

Hi Michal,

On Wed, 2022-02-09 at 13:01 +0100, Michal Suchánek wrote:
> > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > > index dea74d7717c0..1cde9b6c5987 100644
> > > --- a/arch/powerpc/Kconfig
> > > +++ b/arch/powerpc/Kconfig
> > > @@ -560,6 +560,22 @@ config KEXEC_FILE
> > >   config ARCH_HAS_KEXEC_PURGATORY
> > >     def_bool KEXEC_FILE
> > > +config KEXEC_SIG
> > > +   bool "Verify kernel signature during kexec_file_load() syscall"
> > > +   depends on KEXEC_FILE && MODULE_SIG_FORMAT
> > > +   help
> > > +     This option makes kernel signature verification mandatory for
> > > +     the kexec_file_load() syscall.
> > > +
> > > +     In addition to that option, you need to enable signature
> > > +     verification for the corresponding kernel image type being
> > > +     loaded in order for this to work.
> > > +
> > > +     Note: on powerpc IMA_ARCH_POLICY also implements kexec'ed kernel
> > > +     verification. In addition IMA adds kernel hashes to the measurement
> > > +     list, extends IMA PCR in the TPM, and implements kernel image
> > > +     blacklist by hash.
> > 
> > So, what is the takeaway for the user? IMA_ARCH_POLICY is preferred? What is
> > the disadvantage, and two implementations(?) needed then? More overhead?
> 
> IMA_KEXEC does more than KEXEC_SIG. The overhead is probably not big
> unless you are trying to really minimize the kernel code size.
> 
> Arguably the simpler implementation hass less potential for bugs, too.
> Both in code and in user configuration required to enable the feature.
> 
> Interestingly IMA_ARCH_POLICY depends on KEXEC_SIG rather than
> IMA_KEXEC. Just mind-boggling.

FYI, a soft boot doesn't clear the TPM PCRs.  To be able to verify the
IMA measurement list after a kexec against a TPM quote, requires
carrying the measurement list across kexec.

The "IMA_KEXEC" config enables carrying the IMA measurement list across
kexec.  It has nothing to do with verifying the appended signature. 
That is based on kernel module appended signature code.

> 
> The main problem with IMA_KEXEC from my point of view is it is not portable.
> To record the measurements TPM support is requireed which is not available on
> all platforms.

Measuring the kexec kernel image and extending the TPM with the
measurement is required for trusted boot.  Boot loaders extend the
TPM's BIOS measurements. Similarly, IMA does not require a TPM, but if
one is available the kexec kernel image measurement is extended into
the IMA measurement list.  Otherwise, IMA goes into "TPM by-pass" mode.

> It does not support PE so it cannot be used on platforms
> that use PE kernel signature format.

True.  However, a kernel image with an appended signature may be
kexec'ed, regardless of the architecture.  Because some boot loaders
don't support appended signatures, from my point of view does not make
IMA kexec support not portable.

-- 
thanks,

Mimi


WARNING: multiple messages have this Message-ID (diff)
From: Mimi Zohar <zohar@linux.ibm.com>
To: kexec@lists.infradead.org
Subject: [PATCH v5 2/6] powerpc/kexec_file: Add KEXEC_SIG support.
Date: Sun, 13 Feb 2022 12:50:31 -0500	[thread overview]
Message-ID: <b49cb41873655f4fc1269faab5729111d55ce9da.camel@linux.ibm.com> (raw)
In-Reply-To: <20220209120154.GC3113@kunlun.suse.cz>

Hi Michal,

On Wed, 2022-02-09 at 13:01 +0100, Michal Such?nek wrote:
> > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > > index dea74d7717c0..1cde9b6c5987 100644
> > > --- a/arch/powerpc/Kconfig
> > > +++ b/arch/powerpc/Kconfig
> > > @@ -560,6 +560,22 @@ config KEXEC_FILE
> > >   config ARCH_HAS_KEXEC_PURGATORY
> > >     def_bool KEXEC_FILE
> > > +config KEXEC_SIG
> > > +   bool "Verify kernel signature during kexec_file_load() syscall"
> > > +   depends on KEXEC_FILE && MODULE_SIG_FORMAT
> > > +   help
> > > +     This option makes kernel signature verification mandatory for
> > > +     the kexec_file_load() syscall.
> > > +
> > > +     In addition to that option, you need to enable signature
> > > +     verification for the corresponding kernel image type being
> > > +     loaded in order for this to work.
> > > +
> > > +     Note: on powerpc IMA_ARCH_POLICY also implements kexec'ed kernel
> > > +     verification. In addition IMA adds kernel hashes to the measurement
> > > +     list, extends IMA PCR in the TPM, and implements kernel image
> > > +     blacklist by hash.
> > 
> > So, what is the takeaway for the user? IMA_ARCH_POLICY is preferred? What is
> > the disadvantage, and two implementations(?) needed then? More overhead?
> 
> IMA_KEXEC does more than KEXEC_SIG. The overhead is probably not big
> unless you are trying to really minimize the kernel code size.
> 
> Arguably the simpler implementation hass less potential for bugs, too.
> Both in code and in user configuration required to enable the feature.
> 
> Interestingly IMA_ARCH_POLICY depends on KEXEC_SIG rather than
> IMA_KEXEC. Just mind-boggling.

FYI, a soft boot doesn't clear the TPM PCRs.  To be able to verify the
IMA measurement list after a kexec against a TPM quote, requires
carrying the measurement list across kexec.

The "IMA_KEXEC" config enables carrying the IMA measurement list across
kexec.  It has nothing to do with verifying the appended signature. 
That is based on kernel module appended signature code.

> 
> The main problem with IMA_KEXEC from my point of view is it is not portable.
> To record the measurements TPM support is requireed which is not available on
> all platforms.

Measuring the kexec kernel image and extending the TPM with the
measurement is required for trusted boot.  Boot loaders extend the
TPM's BIOS measurements. Similarly, IMA does not require a TPM, but if
one is available the kexec kernel image measurement is extended into
the IMA measurement list.  Otherwise, IMA goes into "TPM by-pass" mode.

> It does not support PE so it cannot be used on platforms
> that use PE kernel signature format.

True.  However, a kernel image with an appended signature may be
kexec'ed, regardless of the architecture.  Because some boot loaders
don't support appended signatures, from my point of view does not make
IMA kexec support not portable.

-- 
thanks,

Mimi



  parent reply	other threads:[~2022-02-13 17:51 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-11 11:37 [PATCH v5 0/6] KEXEC_SIG with appended signature Michal Suchanek
2022-01-11 11:37 ` Michal Suchanek
2022-01-11 11:37 ` Michal Suchanek
2022-01-11 11:37 ` [PATCH v5 1/6] s390/kexec_file: Don't opencode appended signature check Michal Suchanek
2022-01-11 11:37   ` Michal Suchanek
2022-01-11 11:37   ` Michal Suchanek
2022-01-11 11:37 ` [PATCH v5 2/6] powerpc/kexec_file: Add KEXEC_SIG support Michal Suchanek
2022-01-11 11:37   ` Michal Suchanek
2022-01-11 11:37   ` Michal Suchanek
2022-02-09  4:43   ` Michael Ellerman
2022-02-09  4:43     ` Michael Ellerman
2022-02-09  4:43     ` Michael Ellerman
2022-02-09  6:44   ` Paul Menzel
2022-02-09  6:44     ` Paul Menzel
2022-02-09  6:44     ` Paul Menzel
2022-02-09 12:01     ` Michal Suchánek
2022-02-09 12:01       ` Michal =?unknown-8bit?q?Such=C3=A1nek?=
2022-02-09 12:01       ` Michal Suchánek
2022-02-11 15:31       ` Paul Menzel
2022-02-11 15:31         ` Paul Menzel
2022-02-11 15:31         ` Paul Menzel
2022-02-13 17:50       ` Mimi Zohar [this message]
2022-02-13 17:50         ` Mimi Zohar
2022-02-13 17:50         ` Mimi Zohar
2022-02-14  2:59   ` Mimi Zohar
2022-02-14  2:59     ` Mimi Zohar
2022-02-14  2:59     ` Mimi Zohar
2022-02-14 15:14     ` Mimi Zohar
2022-02-14 15:14       ` Mimi Zohar
2022-02-14 15:14       ` Mimi Zohar
2022-02-14 15:55       ` Michal Suchánek
2022-02-14 15:55         ` Michal =?unknown-8bit?q?Such=C3=A1nek?=
2022-02-14 15:55         ` Michal Suchánek
2022-02-14 17:09         ` Mimi Zohar
2022-02-14 17:09           ` Mimi Zohar
2022-02-14 17:09           ` Mimi Zohar
2022-01-11 11:37 ` [PATCH v5 3/6] kexec_file: Don't opencode appended signature verification Michal Suchanek
2022-01-11 11:37   ` Michal Suchanek
2022-01-11 11:37   ` Michal Suchanek
2022-01-25 20:15   ` Luis Chamberlain
2022-01-25 20:15     ` Luis Chamberlain
2022-01-25 20:15     ` Luis Chamberlain
2022-02-03 10:49     ` Michal Suchánek
2022-02-03 10:49       ` Michal =?unknown-8bit?q?Such=C3=A1nek?=
2022-02-03 10:49       ` Michal Suchánek
2022-01-11 11:37 ` [PATCH v5 4/6] module: strip the signature marker in the verification function Michal Suchanek
2022-01-11 11:37   ` Michal Suchanek
2022-01-11 11:37   ` Michal Suchanek
2022-01-25 20:23   ` Luis Chamberlain
2022-01-25 20:23     ` Luis Chamberlain
2022-01-25 20:23     ` Luis Chamberlain
2022-01-11 11:37 ` [PATCH v5 5/6] module: Use key_being_used_for for log messages in verify_appended_signature Michal Suchanek
2022-01-11 11:37   ` Michal Suchanek
2022-01-11 11:37   ` Michal Suchanek
2022-01-25 20:24   ` Luis Chamberlain
2022-01-25 20:24     ` Luis Chamberlain
2022-01-25 20:24     ` Luis Chamberlain
2022-01-11 11:37 ` [PATCH v5 6/6] module: Move duplicate mod_check_sig users code to mod_parse_sig Michal Suchanek
2022-01-11 11:37   ` Michal Suchanek
2022-01-11 11:37   ` Michal Suchanek
2022-01-25 20:27   ` Luis Chamberlain
2022-01-25 20:27     ` Luis Chamberlain
2022-01-25 20:27     ` Luis Chamberlain
2022-01-25 20:30 ` [PATCH v5 0/6] KEXEC_SIG with appended signature Luis Chamberlain
2022-01-25 20:30   ` Luis Chamberlain
2022-01-25 20:30   ` Luis Chamberlain
2022-02-09  4:46   ` Michael Ellerman
2022-02-09  4:46     ` Michael Ellerman
2022-02-09  4:46     ` Michael Ellerman
2022-02-10 23:30     ` Luis Chamberlain
2022-02-10 23:30       ` Luis Chamberlain
2022-02-10 23:30       ` Luis Chamberlain
2022-02-13 18:53 ` Mimi Zohar
2022-02-13 18:53   ` Mimi Zohar
2022-02-13 18:53   ` Mimi Zohar
2022-02-13 20:27 ` Mimi Zohar
2022-02-13 20:27   ` Mimi Zohar
2022-02-13 20:27   ` Mimi Zohar

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=b49cb41873655f4fc1269faab5729111d55ce9da.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=bauerman@linux.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=bhe@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=buendgen@de.ibm.com \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=dja@axtens.net \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=fllinden@amazon.com \
    --cc=gor@linux.ibm.com \
    --cc=hbathini@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=jeyu@kernel.org \
    --cc=jmorris@namei.org \
    --cc=kexec@lists.infradead.org \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mcgrof@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=msuchanek@suse.de \
    --cc=nayna@linux.vnet.ibm.com \
    --cc=nramas@linux.microsoft.com \
    --cc=paulus@samba.org \
    --cc=pmenzel@molgen.mpg.de \
    --cc=prudo@redhat.com \
    --cc=robh@kernel.org \
    --cc=serge@hallyn.com \
    --cc=svens@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.