LinuxPPC-Dev Archive on lore.kernel.org
 help / color / Atom feed
* Re: [PATCH v2] ima: defer arch_ima_get_secureboot() call to IMA init time
       [not found] <20201013081804.17332-1-ardb@kernel.org>
@ 2020-10-13 16:46 ` Mimi Zohar
  2020-10-13 16:59   ` Ard Biesheuvel
  0 siblings, 1 reply; 6+ messages in thread
From: Mimi Zohar @ 2020-10-13 16:46 UTC (permalink / raw)
  To: Ard Biesheuvel, linux-efi
  Cc: Dmitry Kasatkin, James Morris, Chester Lin,
	linux-security-module, linux-integrity, linuxppc-dev,
	Serge E. Hallyn

[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.

thanks,

Mimi


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v2] ima: defer arch_ima_get_secureboot() call to IMA init time
  2020-10-13 16:46 ` [PATCH v2] ima: defer arch_ima_get_secureboot() call to IMA init time Mimi Zohar
@ 2020-10-13 16:59   ` Ard Biesheuvel
  2020-10-13 19:45     ` Mimi Zohar
  2020-10-14  9:35     ` Chester Lin
  0 siblings, 2 replies; 6+ messages in thread
From: Ard Biesheuvel @ 2020-10-13 16:59 UTC (permalink / raw)
  To: Mimi Zohar
  Cc: linux-efi, Dmitry Kasatkin, James Morris, Chester Lin,
	linux-security-module, linux-integrity,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	Serge E. Hallyn

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.
>

Thanks. No rush as far as I am concerned, although I suppose Chester
may want to rebase his arm64 IMA enablement series on this.

Suggestion: can we take the get_sb_mode() code from ima_arch.c in
arch/x86, and generalize it for all EFI architectures? That way, we
can enable 32-bit ARM and RISC-V seamlessly once someone gets around
to enabling IMA on those platforms. In fact, get_sb_mode() itself
should probably be factored out into a generic helper for use outside
of IMA as well (Xen/x86 has code that does roughly the same already)

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v2] ima: defer arch_ima_get_secureboot() call to IMA init time
  2020-10-13 16:59   ` Ard Biesheuvel
@ 2020-10-13 19:45     ` Mimi Zohar
  2020-10-14  9:35     ` Chester Lin
  1 sibling, 0 replies; 6+ messages in thread
From: Mimi Zohar @ 2020-10-13 19:45 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: linux-efi, Dmitry Kasatkin, James Morris, Chester Lin,
	linux-security-module, linux-integrity,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	Serge E. Hallyn

On Tue, 2020-10-13 at 18:59 +0200, Ard Biesheuvel wrote:
> Suggestion: can we take the get_sb_mode() code from ima_arch.c in
> arch/x86, and generalize it for all EFI architectures? That way, we
> can enable 32-bit ARM and RISC-V seamlessly once someone gets around
> to enabling IMA on those platforms. In fact, get_sb_mode() itself
> should probably be factored out into a generic helper for use outside
> of IMA as well (Xen/x86 has code that does roughly the same already)

On Power, there are three different policies - secure, trusted, and
secure & trusted boot policy rules.  Based on whether secure or trusted
boot is enabled, the appropriate policy is enabled.  On x86, if
secure_boot is enabled (and CONFIG_IMA_ARCH_POLICY is enabled) both the
secure and trusted boot rules are defined.  Is this design fine enough
granularity or should should there be a get_trustedboot_mode() function
as well?

Agreed, the code should not be duplicated across arch's.  As for making
get_sb_mode() generic, not dependent on IMA, where would it reside? 
Would this be in EFI?

thanks,

Mimi


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v2] ima: defer arch_ima_get_secureboot() call to IMA init time
  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
  1 sibling, 1 reply; 6+ messages in thread
From: Chester Lin @ 2020-10-14  9:35 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: linux-efi, Dmitry Kasatkin, James Morris, Mimi Zohar, jlee,
	linux-security-module, linux-integrity,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	Serge E. Hallyn

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
  ....

> 
> Thanks. No rush as far as I am concerned, although I suppose Chester
> may want to rebase his arm64 IMA enablement series on this.

Yes, I've finished coding but still verifying it. As you have suggested,
My v2 patch will separate the get_sb_mode() from arch/x86 so that other
architectures can reuse it.

Thanks,
Chester

> 
> Suggestion: can we take the get_sb_mode() code from ima_arch.c in
> arch/x86, and generalize it for all EFI architectures? That way, we
> can enable 32-bit ARM and RISC-V seamlessly once someone gets around
> to enabling IMA on those platforms. In fact, get_sb_mode() itself
> should probably be factored out into a generic helper for use outside
> of IMA as well (Xen/x86 has code that does roughly the same already)
> 


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v2] ima: defer arch_ima_get_secureboot() call to IMA init time
  2020-10-14  9:35     ` Chester Lin
@ 2020-10-14 11:38       ` Mimi Zohar
  2020-10-15 12:16         ` Chester Lin
  0 siblings, 1 reply; 6+ messages in thread
From: Mimi Zohar @ 2020-10-14 11:38 UTC (permalink / raw)
  To: Chester Lin, Ard Biesheuvel
  Cc: linux-efi, Dmitry Kasatkin, James Morris, jlee,
	linux-security-module, linux-integrity,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	Serge E. Hallyn

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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v2] ima: defer arch_ima_get_secureboot() call to IMA init time
  2020-10-14 11:38       ` Mimi Zohar
@ 2020-10-15 12:16         ` Chester Lin
  0 siblings, 0 replies; 6+ messages in thread
From: Chester Lin @ 2020-10-15 12:16 UTC (permalink / raw)
  To: Mimi Zohar
  Cc: clin, linux-efi, Dmitry Kasatkin, James Morris, jlee,
	linux-security-module, linux-integrity,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	Ard Biesheuvel, Serge E. Hallyn

On Wed, Oct 14, 2020 at 07:38:50AM -0400, Mimi Zohar wrote:
> 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
>

Last time I didn't emulate a TPM device in KVM so that's why the kernel couldn't
find a TPM chip. I have tested this patch again with a virtual TPM 1.2 by
running swtpm and here are some logs:

-----
[    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] efi: EFI v2.60 by EDK II
[    0.000000] efi: SMBIOS=0x7fe82000 ACPI=0x7feb0000 ACPI 2.0=0x7feb0014 MEMATTT
R=0x7ef89698 RNG=0x7ea12e18
[    0.000000] efi: seeding entropy pool
[    0.000000] random: fast init done
[    0.000000] SMBIOS 2.8 present.
[    0.000000] DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
[    0.000000] Hypervisor detected: KVM
.....
.....
[    1.957625] Linux agpgart interface v0.103
[    1.961903] tpm_tis 00:04: 1.2 TPM (device-id 0x1, rev-id 1)
[    1.966306] tpm tpm0: starting up the TPM manually
[    1.981753] ahci 0000:00:1f.2: version 3.0
[    1.984503] PCI Interrupt Link [GSIA] enabled at IRQ 16
.....
.....
[    2.086645] ima: Secure boot enabled: ignoring ima_appraise=off option
[    2.086650] ima: Allocated hash algorithm: sha256
[    2.100662] evm: Initialising EVM extended attributes:
[    2.100689] audit: type=1807 audit(1602760724.564:2): action=measure func=KEX
EC_KERNEL_CHECK res=1
[    2.101849] evm: security.selinux
[    2.101849] evm: security.apparmor
[    2.101849] evm: security.ima
[    2.101850] evm: security.capability
[    2.101850] evm: HMAC attrs: 0x1
[    2.102083] PM:   Magic number: 8:588:327
[    2.106723] audit: type=1807 audit(1602760724.564:3): action=measure func=MODD
ULE_CHECK res=1
[    2.118761] RAS: Correctable Errors collector initialized.
.....
-----


In terms of TPM 2.0, swtpm seems to have issues while running the selftest so
I verified this patch on my laptop as well because it has a real TPM 2.0 chip:

-----
[    0.000000] microcode: microcode updated early to revision 0xd6, date = 2020-
04-27
[    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 1404:00:11 UTC 2020 (8764d18)
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.9.0-858-g865c50e1d279-1.
g8764d18-vanilla root=UUID=2184bbb7-780e-48a2-98b8-3a8cd3366e5e splash=silent re
sume=/dev/disk/by-id/ata-INTEL_SSDSCKKF512G8_SATA_512GB_BTLA82850G3E512K-part3 i
gnore_loglevel crashkernel=222M,high crashkernel=72M,low ima_appraise=log
[    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point regi
sters'
.....
.....
[    0.000000] efi: EFI v2.60 by American Megatrends
[    0.000000] efi: ACPI=0x7a34e000 ACPI 2.0=0x7a34e000 SMBIOS=0xf0000 SMBIOS 3.
0=0xf0020 TPMFinalLog=0x7ac8b000 ESRT=0x7b0e0018 MEMATTR=0x7762d018 RNG=0x7b133f
18 TPMEventLog=0x6ab96018
[    0.000000] efi: seeding entropy pool
[    0.000000] random: fast init done
[    0.000000] SMBIOS 3.1.0 present.
[    0.000000] DMI: Dell Inc. Latitude 7490/0KP0FT, BIOS 1.14.0 01/22/2020
.....
.....
[    7.182711] Non-volatile memory driver v1.3
[    7.182748] Linux agpgart interface v0.103
[    7.210826] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFC, rev-id 1)
[    7.234324] ahci 0000:00:17.0: version 3.0
.....
.....
[    7.288573] integrity: Loading X.509 certificate: UEFI:MokListRT
[    7.289299] integrity: Loaded X.509 cert 'openSUSE Secure Boot CA: 6842600de22c4c477e95be23dfea9513e5971762'
[    7.289913] ima: Secure boot enabled: ignoring ima_appraise=log option
[    7.289921] ima: Allocated hash algorithm: sha256
[    7.314854] evm: Initialising EVM extended attributes:
[    7.314878] audit: type=1807 audit(1602778176.572:2): action=measure func=KEXEC_KERNEL_CHECK res=1
[    7.316656] evm: security.selinux
[    7.316659] evm: security.apparmor
[    7.318493] audit: type=1807 audit(1602778176.572:3): action=measure func=MODULE_CHECK res=1
[    7.320092] evm: security.ima
[    7.320093] evm: security.capability
[    7.322554] evm: HMAC attrs: 0x1


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, back to index

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20201013081804.17332-1-ardb@kernel.org>
2020-10-13 16:46 ` [PATCH v2] ima: defer arch_ima_get_secureboot() call to IMA init time 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
2020-10-15 12:16         ` Chester Lin

LinuxPPC-Dev Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linuxppc-dev/0 linuxppc-dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linuxppc-dev linuxppc-dev/ https://lore.kernel.org/linuxppc-dev \
		linuxppc-dev@lists.ozlabs.org linuxppc-dev@ozlabs.org
	public-inbox-index linuxppc-dev

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.ozlabs.lists.linuxppc-dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git