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
next prev parent reply other threads:[~2020-10-14 11:39 UTC|newest]
Thread overview: 7+ 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:59 ` Ard Biesheuvel
2020-10-13 19:45 ` Mimi Zohar
2020-10-14 9:35 ` Chester Lin
2020-10-14 11:38 ` Mimi Zohar [this message]
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 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).