lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1571190256.5250.200.camel@linux.ibm.com>
Date:   Tue, 15 Oct 2019 21:44:16 -0400
From:   Mimi Zohar <zohar@...ux.ibm.com>
To:     James Morse <james.morse@....com>,
        prsriva <prsriva@...ux.microsoft.com>,
        Thiago Jung Bauermann <bauerman@...ux.ibm.com>
Cc:     linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-integrity@...r.kernel.org, kexec@...ts.infradead.org,
        mark.rutland@....com, jean-philippe@...aro.org, arnd@...db.de,
        takahiro.akashi@...aro.org, sboyd@...nel.org,
        catalin.marinas@....com, yamada.masahiro@...ionext.com,
        duwe@....de, bauerman@...ux.ibm.com, tglx@...utronix.de,
        allison@...utok.net, ard.biesheuvel@...aro.org
Subject: Re: [PATCH V4 0/2] Add support for arm64 to carry ima measurement

Hi James,

On Tue, 2019-10-15 at 18:39 +0100, James Morse wrote:
> If SecureBoot isn't relevant, I'm confused as to why kexec_file_load() is.
> 
> I thought kexec_file_load() only existed because SecureBoot systems need to validate the
> new OS images's signature before loading it, and we can't trust user-space calling Kexec
> to do this.
> 
> If there is no secure boot, why does this thing only work with kexec_file_load()?
> (good news! With the UEFI memreseve table, it should work transparently with regular kexec
> too)

I'm so sorry for the confusion.  IMA was originally limited to
extending trusted boot concepts to the OS.  As of Linux 3.10, IMA
added support for extending secure boot concepts and auditing file
hashes (commit e7c568e0fd0cf).

True, kexec_file_load is required for verifying the kexec kernel
image, but it is also required for measuring the kexec kernel image as
well.

After reading the kernel image into memory (kernel_read_file_from_fd),
the hash is calculated and then added to the IMA measurement list and
used to extend the TPM.  All of this is based on the IMA policy,
including the TPM PCR.

> 
> > I am not sure if i addressed all your concerns, please let me know
> > if i missed anything. To me most concerns look to be towards the kexec case and dependency
> > on hardware(ACPI/TPM) during boot and early boot services, where as carrying the logs is
> > only during the kexec_file_load sys call and does not interfere with that code path.
> > IMA documentation: https://sourceforge.net/p/linux-ima/wiki/Home/
> 
> Supporting ACPI in the same way is something we need to do from day one. kexec_file_load()
> already does this. I'm not sure "only kexec_file_load()" is a justifiable restriction...

The TPM PCRs are not reset on a soft reboot.  As a result, in order to
validate the IMA measurement list against the TPM PCRs, the IMA
measurement list is saved on kexec load, restored on boot, and then
the memory allocated for carrying the measurement list across kexec is
freed.

Where/how to save the IMA measurement list is architecture dependent.
 Thiago Bauermann implemented allocating and freeing the measurement
list memory for Power.

Mimi

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ