All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: Chester Lin <clin@suse.com>, Ard Biesheuvel <ardb@kernel.org>
Cc: linux-efi <linux-efi@vger.kernel.org>,
	linux-integrity <linux-integrity@vger.kernel.org>,
	linux-security-module@vger.kernel.org,
	Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
	James Morris <jmorris@namei.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	"open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)" 
	<linuxppc-dev@lists.ozlabs.org>,
	jlee@suse.com
Subject: Re: [PATCH v2] ima: defer arch_ima_get_secureboot() call to IMA init time
Date: Wed, 14 Oct 2020 07:38:50 -0400	[thread overview]
Message-ID: <98b04c130708893ebefdf81e127a66356b4a6129.camel@linux.ibm.com> (raw)
In-Reply-To: <20201014093531.GA9408@linux-8mug>

On Wed, 2020-10-14 at 17:35 +0800, Chester Lin wrote:
> Hi Ard & Mimi,
> 
> On Tue, Oct 13, 2020 at 06:59:21PM +0200, Ard Biesheuvel wrote:
> > On Tue, 13 Oct 2020 at 18:46, Mimi Zohar <zohar@linux.ibm.com> wrote:
> > >
> > > [Cc'ing linuxppc-dev@lists.ozlabs.org]
> > >
> > > On Tue, 2020-10-13 at 10:18 +0200, Ard Biesheuvel wrote:
> > > > Chester reports that it is necessary to introduce a new way to pass
> > > > the EFI secure boot status between the EFI stub and the core kernel
> > > > on ARM systems. The usual way of obtaining this information is by
> > > > checking the SecureBoot and SetupMode EFI variables, but this can
> > > > only be done after the EFI variable workqueue is created, which
> > > > occurs in a subsys_initcall(), whereas arch_ima_get_secureboot()
> > > > is called much earlier by the IMA framework.
> > > >
> > > > However, the IMA framework itself is started as a late_initcall,
> > > > and the only reason the call to arch_ima_get_secureboot() occurs
> > > > so early is because it happens in the context of a __setup()
> > > > callback that parses the ima_appraise= command line parameter.
> > > >
> > > > So let's refactor this code a little bit, by using a core_param()
> > > > callback to capture the command line argument, and deferring any
> > > > reasoning based on its contents to the IMA init routine.
> > > >
> > > > Cc: Chester Lin <clin@suse.com>
> > > > Cc: Mimi Zohar <zohar@linux.ibm.com>
> > > > Cc: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>
> > > > Cc: James Morris <jmorris@namei.org>
> > > > Cc: "Serge E. Hallyn" <serge@hallyn.com>
> > > > Link: https://lore.kernel.org/linux-arm-kernel/20200904072905.25332-2-clin@suse.com/
> > > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> > > > ---
> > > > v2: rebase onto series 'integrity: improve user feedback for invalid bootparams'
> > >
> > > Thanks, Ard.  Based on my initial, limited testing on Power, it looks
> > > good, but I'm hesistant to include it in the integrity 5.10 pull
> > > request without it having been in linux-next and some additional
> > > testing.  It's now queued in the next-integrity-testing branch awaiting
> > > some tags.
> > >
> 
> Tested-by: Chester Lin <clin@suse.com>
> 
> I have tested this patch on x86 VM.
> 
> * System configuration:
>   - Platform: QEMU/KVM
>   - Firmware: EDK2/OVMF + secure boot enabled.
>   - OS: SLE15-SP2 + SUSE's kernel-vanilla (=linux v5.9) + the follow commits
>     from linux-next and upstream:
>     * [PATCH v2] ima: defer arch_ima_get_secureboot() call to IMA init time
>       https://www.spinics.net/lists/linux-efi/msg20645.html
>     * e4d7e2df3a09 "ima: limit secure boot feedback scope for appraise"
>     * 7fe2bb7e7e5c "integrity: invalid kernel parameters feedback"
>     * 4afb28ab03d5 "ima: add check for enforced appraise option"
> 
> * Logs with UEFI secure boot enabled:
> 
>   [    0.000000] Linux version 5.9.0-858-g865c50e1d279-1.g8764d18-vanilla (geeko@b
>   uildhost) (gcc (SUSE Linux) 10.2.1 20200825 [revision c0746a1beb1ba073c7981eb09f
>   55b3d993b32e5c], GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.34.0.20200325-1) #
>   1 SMP Wed Oct 14 04:00:11 UTC 2020 (8764d18)
>   [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.9.0-858-g865c50e1d279-1.
>   g8764d18-vanilla root=UUID=5304c03e-4d8a-4d67-873a-32a32e57cdeb console=ttyS0,11
>   5200 resume=/dev/disk/by-path/pci-0000:04:00.0-part4 mitigations=auto ignore_log
>   level crashkernel=192M,high crashkernel=72M,low ima_appraise=off
>   [    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point regi
>   sters'
>   [    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
>   [    0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
>   ....
>   ....
>   [    1.720309] ima: Secure boot enabled: ignoring ima_appraise=off option
>   [    1.720314] ima: No TPM chip found, activating TPM-bypass!
>   [    1.722129] ima: Allocated hash algorithm: sha256


Thank you for testing the options aren't being set in secure boot mode.
My main concern, however, is that IMA doesn't go into TPM-bypass mode. 
Does this system have a TPM?

Mimi


WARNING: multiple messages have this Message-ID (diff)
From: Mimi Zohar <zohar@linux.ibm.com>
To: Chester Lin <clin@suse.com>, Ard Biesheuvel <ardb@kernel.org>
Cc: linux-efi <linux-efi@vger.kernel.org>,
	Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
	James Morris <jmorris@namei.org>,
	jlee@suse.com, linux-security-module@vger.kernel.org,
	linux-integrity <linux-integrity@vger.kernel.org>,
	"open list:LINUX FOR POWERPC \(32-BIT AND 64-BIT\)"
	<linuxppc-dev@lists.ozlabs.org>,
	"Serge E. Hallyn" <serge@hallyn.com>
Subject: Re: [PATCH v2] ima: defer arch_ima_get_secureboot() call to IMA init time
Date: Wed, 14 Oct 2020 07:38:50 -0400	[thread overview]
Message-ID: <98b04c130708893ebefdf81e127a66356b4a6129.camel@linux.ibm.com> (raw)
In-Reply-To: <20201014093531.GA9408@linux-8mug>

On Wed, 2020-10-14 at 17:35 +0800, Chester Lin wrote:
> Hi Ard & Mimi,
> 
> On Tue, Oct 13, 2020 at 06:59:21PM +0200, Ard Biesheuvel wrote:
> > On Tue, 13 Oct 2020 at 18:46, Mimi Zohar <zohar@linux.ibm.com> wrote:
> > >
> > > [Cc'ing linuxppc-dev@lists.ozlabs.org]
> > >
> > > On Tue, 2020-10-13 at 10:18 +0200, Ard Biesheuvel wrote:
> > > > Chester reports that it is necessary to introduce a new way to pass
> > > > the EFI secure boot status between the EFI stub and the core kernel
> > > > on ARM systems. The usual way of obtaining this information is by
> > > > checking the SecureBoot and SetupMode EFI variables, but this can
> > > > only be done after the EFI variable workqueue is created, which
> > > > occurs in a subsys_initcall(), whereas arch_ima_get_secureboot()
> > > > is called much earlier by the IMA framework.
> > > >
> > > > However, the IMA framework itself is started as a late_initcall,
> > > > and the only reason the call to arch_ima_get_secureboot() occurs
> > > > so early is because it happens in the context of a __setup()
> > > > callback that parses the ima_appraise= command line parameter.
> > > >
> > > > So let's refactor this code a little bit, by using a core_param()
> > > > callback to capture the command line argument, and deferring any
> > > > reasoning based on its contents to the IMA init routine.
> > > >
> > > > Cc: Chester Lin <clin@suse.com>
> > > > Cc: Mimi Zohar <zohar@linux.ibm.com>
> > > > Cc: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>
> > > > Cc: James Morris <jmorris@namei.org>
> > > > Cc: "Serge E. Hallyn" <serge@hallyn.com>
> > > > Link: https://lore.kernel.org/linux-arm-kernel/20200904072905.25332-2-clin@suse.com/
> > > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> > > > ---
> > > > v2: rebase onto series 'integrity: improve user feedback for invalid bootparams'
> > >
> > > Thanks, Ard.  Based on my initial, limited testing on Power, it looks
> > > good, but I'm hesistant to include it in the integrity 5.10 pull
> > > request without it having been in linux-next and some additional
> > > testing.  It's now queued in the next-integrity-testing branch awaiting
> > > some tags.
> > >
> 
> Tested-by: Chester Lin <clin@suse.com>
> 
> I have tested this patch on x86 VM.
> 
> * System configuration:
>   - Platform: QEMU/KVM
>   - Firmware: EDK2/OVMF + secure boot enabled.
>   - OS: SLE15-SP2 + SUSE's kernel-vanilla (=linux v5.9) + the follow commits
>     from linux-next and upstream:
>     * [PATCH v2] ima: defer arch_ima_get_secureboot() call to IMA init time
>       https://www.spinics.net/lists/linux-efi/msg20645.html
>     * e4d7e2df3a09 "ima: limit secure boot feedback scope for appraise"
>     * 7fe2bb7e7e5c "integrity: invalid kernel parameters feedback"
>     * 4afb28ab03d5 "ima: add check for enforced appraise option"
> 
> * Logs with UEFI secure boot enabled:
> 
>   [    0.000000] Linux version 5.9.0-858-g865c50e1d279-1.g8764d18-vanilla (geeko@b
>   uildhost) (gcc (SUSE Linux) 10.2.1 20200825 [revision c0746a1beb1ba073c7981eb09f
>   55b3d993b32e5c], GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.34.0.20200325-1) #
>   1 SMP Wed Oct 14 04:00:11 UTC 2020 (8764d18)
>   [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.9.0-858-g865c50e1d279-1.
>   g8764d18-vanilla root=UUID=5304c03e-4d8a-4d67-873a-32a32e57cdeb console=ttyS0,11
>   5200 resume=/dev/disk/by-path/pci-0000:04:00.0-part4 mitigations=auto ignore_log
>   level crashkernel=192M,high crashkernel=72M,low ima_appraise=off
>   [    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point regi
>   sters'
>   [    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
>   [    0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
>   ....
>   ....
>   [    1.720309] ima: Secure boot enabled: ignoring ima_appraise=off option
>   [    1.720314] ima: No TPM chip found, activating TPM-bypass!
>   [    1.722129] ima: Allocated hash algorithm: sha256


Thank you for testing the options aren't being set in secure boot mode.
My main concern, however, is that IMA doesn't go into TPM-bypass mode. 
Does this system have a TPM?

Mimi


  reply	other threads:[~2020-10-14 11:39 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-13  8:18 [PATCH v2] ima: defer arch_ima_get_secureboot() call to IMA init time Ard Biesheuvel
2020-10-13 16:46 ` Mimi Zohar
2020-10-13 16:46   ` Mimi Zohar
2020-10-13 16:59   ` Ard Biesheuvel
2020-10-13 16:59     ` Ard Biesheuvel
2020-10-13 19:45     ` Mimi Zohar
2020-10-13 19:45       ` Mimi Zohar
2020-10-14  9:35     ` Chester Lin
2020-10-14  9:35       ` Chester Lin
2020-10-14 11:38       ` Mimi Zohar [this message]
2020-10-14 11:38         ` Mimi Zohar
2020-10-15 12:16         ` Chester Lin
2020-10-15 12:16           ` Chester Lin

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=98b04c130708893ebefdf81e127a66356b4a6129.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --cc=ardb@kernel.org \
    --cc=clin@suse.com \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=jlee@suse.com \
    --cc=jmorris@namei.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=serge@hallyn.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.