[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1473954263.2526.88.camel@linux.vnet.ibm.com>
Date: Thu, 15 Sep 2016 11:44:23 -0400
From: Mimi Zohar <zohar@...ux.vnet.ibm.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: linux-security-module <linux-security-module@...r.kernel.org>,
linux-ima-devel@...ts.sourceforge.net,
Dave Young <dyoung@...hat.com>, kexec@...ts.infradead.org,
linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
Thiago Jung Bauermann <bauerman@...ux.vnet.ibm.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: [PATHC v2 0/9] ima: carry the measurement list across kexec
Hi Andrew,
On Wed, 2016-08-31 at 18:38 -0400, Mimi Zohar wrote:
> On Wed, 2016-08-31 at 13:50 -0700, Andrew Morton wrote:
> > On Tue, 30 Aug 2016 18:40:02 -0400 Mimi Zohar <zohar@...ux.vnet.ibm.com> wrote:
> >
> > > The TPM PCRs are only reset on a hard reboot. In order to validate a
> > > TPM's quote after a soft reboot (eg. kexec -e), the IMA measurement list
> > > of the running kernel must be saved and then restored on the subsequent
> > > boot, possibly of a different architecture.
> > >
> > > The existing securityfs binary_runtime_measurements file conveniently
> > > provides a serialized format of the IMA measurement list. This patch
> > > set serializes the measurement list in this format and restores it.
> > >
> > > Up to now, the binary_runtime_measurements was defined as architecture
> > > native format. The assumption being that userspace could and would
> > > handle any architecture conversions. With the ability of carrying the
> > > measurement list across kexec, possibly from one architecture to a
> > > different one, the per boot architecture information is lost and with it
> > > the ability of recalculating the template digest hash. To resolve this
> > > problem, without breaking the existing ABI, this patch set introduces
> > > the boot command line option "ima_canonical_fmt", which is arbitrarily
> > > defined as little endian.
> > >
> > > The need for this boot command line option will be limited to the
> > > existing version 1 format of the binary_runtime_measurements.
> > > Subsequent formats will be defined as canonical format (eg. TPM 2.0
> > > support for larger digests).
> > >
> > > This patch set pre-req's Thiago Bauermann's "kexec_file: Add buffer
> > > hand-over for the next kernel" patch set.
> > >
> > > These patches can also be found in the next-kexec-restore branch of:
> > > git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git
> >
> > I'll merge these into -mm to get some linux-next exposure. I don't
> > know what your upstream merge plans will be?
>
> Sounds good. I'm hoping to get some review/comments on this patch set
> as well. At the moment, I'm chasing down a kernel test robot report
> from this afternoon.
My concern about changing the canonical format as originally defined in
patch 9/9 from big endian to little endian never materialized. Andreas
Steffan, the patch author, is happy either way.
We proposed two methods of addressing Eric Biederman's concerns of not
including the IMA measurement list segment in the kexec hash as
described in https://lkml.org/lkml/2016/9/9/355.
- defer calculating and verifying the serialized IMA measurement list
buffer hash to IMA
- calculate the kexec hash on load, verify it on the kexec execute,
before re-calculating and updating it.
We implemented both options, which can be found in the
next-kexec-restore.with-ima-checksum and next-kexec-restore branches of:
git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git
Thiago's patches posted yesterday and mine posted this morning are based
on kexec doing the hashing (the second option).
Lastly, we've addressed the automated kernel build and runtime bug
reports.
Since the IMA patches are dependent on the kexec ones, the two patch
sets need to be upstreamed together. How should we proceed? Should
they be upstreamed through your tree?
Mimi
Powered by blists - more mailing lists