From: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Stewart Smith <stewart@linux.vnet.ibm.com>,
Baoquan He <bhe@redhat.com>, Dave Young <dyoung@redhat.com>,
Balbir Singh <bsingharora@gmail.com>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
Eric Richter <erichte@linux.vnet.ibm.com>,
Michael Ellerman <mpe@ellerman.id.au>,
linux-ima-devel@lists.sourceforge.net,
Andrew Morton <akpm@linux-foundation.org>,
Mimi Zohar <zohar@linux.vnet.ibm.com>,
linuxppc-dev@lists.ozlabs.org, Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [PATCH v4 0/5] kexec_file: Add buffer hand-over for the next kernel
Date: Thu, 08 Sep 2016 16:20:45 -0300 [thread overview]
Message-ID: <3106532.NfQxgDJQ20@hactar> (raw)
In-Reply-To: <871t0vlrlv.fsf@x220.int.ebiederm.org>
Am Mittwoch, 07 September 2016, 09:19:40 schrieb Eric W. Biederman:
> ebiederm@xmission.com (Eric W. Biederman) writes:
> > Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> writes:
> >> Hello,
> >>
> >> The purpose of this new version of the series is to fix a small issue
> >> that I found, which is that the kernel doesn't remove the memory
> >> reservation for the hand-over buffer it received from the previous
> >> kernel in the device tree it sets up for the next kernel. The result
> >> is that for each successive kexec, a stale hand-over buffer is left
> >> behind, wasting memory.
> >>
> >> This is fixed by changes to kexec_free_handover_buffer and
> >> setup_handover_buffer in patch 2. The other change is to fix checkpatch
> >> warnings in the last patch.
> >
> > This is fundamentally broken. You do not increase the integrity of a
> > system by dropping integrity checks.
> >
> > No. No. No. No.
> >
> > Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
The IMA measurement list can be verified without the need of a checksum over
its contents by replaying the PCR extend operations and checking that the
result matches the registers in the TPM device. So the fact that it is not
part of the kexec segments checksum verification doesn't actually reduce the
integrity of the system.
Currently, IMA doesn't perform that verification when it restores the
measurement list from the kexec handover buffer, so if you believe it's
necessary to do that check at boot time, we could do one of the following:
1. Have IMA replay the PCR extend operations when it restores the
measurement list from the handover buffer and validate it against the TPM
PCRs, or
2. Have a buffer hash in the ima_kexec_hdr that IMA includes in the handover
buffer, and verify the buffer checksum before restoring the measurement
list.
What do you think?
> To be constructive the way we have handled similiar situations in the
> past (hotplu memory) is to call kexec_load again.
Thanks for your suggestion. Unfortunately it's always possible for new
measurements to be added to the measurement list between the kexec_file_load
and the reboot. We see that happen in practice with system scripts and
configuration files that are only read or executed during the reboot
process. They are only measured by IMA as a result of the kexec execute.
--
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: kexec@lists.infradead.org, linux-security-module@vger.kernel.org,
linux-ima-devel@lists.sourceforge.net,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Dave Young <dyoung@redhat.com>, Vivek Goyal <vgoyal@redhat.com>,
Baoquan He <bhe@redhat.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Stewart Smith <stewart@linux.vnet.ibm.com>,
Mimi Zohar <zohar@linux.vnet.ibm.com>,
Eric Richter <erichte@linux.vnet.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Balbir Singh <bsingharora@gmail.com>
Subject: Re: [PATCH v4 0/5] kexec_file: Add buffer hand-over for the next kernel
Date: Thu, 08 Sep 2016 16:20:45 -0300 [thread overview]
Message-ID: <3106532.NfQxgDJQ20@hactar> (raw)
In-Reply-To: <871t0vlrlv.fsf@x220.int.ebiederm.org>
Am Mittwoch, 07 September 2016, 09:19:40 schrieb Eric W. Biederman:
> ebiederm@xmission.com (Eric W. Biederman) writes:
> > Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> writes:
> >> Hello,
> >>
> >> The purpose of this new version of the series is to fix a small issue
> >> that I found, which is that the kernel doesn't remove the memory
> >> reservation for the hand-over buffer it received from the previous
> >> kernel in the device tree it sets up for the next kernel. The result
> >> is that for each successive kexec, a stale hand-over buffer is left
> >> behind, wasting memory.
> >>
> >> This is fixed by changes to kexec_free_handover_buffer and
> >> setup_handover_buffer in patch 2. The other change is to fix checkpatch
> >> warnings in the last patch.
> >
> > This is fundamentally broken. You do not increase the integrity of a
> > system by dropping integrity checks.
> >
> > No. No. No. No.
> >
> > Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
The IMA measurement list can be verified without the need of a checksum over
its contents by replaying the PCR extend operations and checking that the
result matches the registers in the TPM device. So the fact that it is not
part of the kexec segments checksum verification doesn't actually reduce the
integrity of the system.
Currently, IMA doesn't perform that verification when it restores the
measurement list from the kexec handover buffer, so if you believe it's
necessary to do that check at boot time, we could do one of the following:
1. Have IMA replay the PCR extend operations when it restores the
measurement list from the handover buffer and validate it against the TPM
PCRs, or
2. Have a buffer hash in the ima_kexec_hdr that IMA includes in the handover
buffer, and verify the buffer checksum before restoring the measurement
list.
What do you think?
> To be constructive the way we have handled similiar situations in the
> past (hotplu memory) is to call kexec_load again.
Thanks for your suggestion. Unfortunately it's always possible for new
measurements to be added to the measurement list between the kexec_file_load
and the reboot. We see that happen in practice with system scripts and
configuration files that are only read or executed during the reboot
process. They are only measured by IMA as a result of the kexec execute.
--
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center
next prev parent reply other threads:[~2016-09-08 19:21 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-30 17:45 [PATCH v4 0/5] kexec_file: Add buffer hand-over for the next kernel Thiago Jung Bauermann
2016-08-30 17:45 ` Thiago Jung Bauermann
2016-08-30 17:45 ` [PATCH v4 1/5] kexec_file: Add buffer hand-over support " Thiago Jung Bauermann
2016-08-30 17:45 ` Thiago Jung Bauermann
2016-08-30 17:45 ` [PATCH v4 2/5] powerpc: " Thiago Jung Bauermann
2016-08-30 17:45 ` Thiago Jung Bauermann
2016-08-30 17:45 ` [PATCH v4 3/5] kexec_file: Allow skipping checksum calculation for some segments Thiago Jung Bauermann
2016-08-30 17:45 ` Thiago Jung Bauermann
2016-09-07 1:30 ` Eric W. Biederman
2016-09-07 1:30 ` Eric W. Biederman
2016-08-30 17:45 ` [PATCH v4 4/5] kexec_file: Add mechanism to update kexec segments Thiago Jung Bauermann
2016-08-30 17:45 ` Thiago Jung Bauermann
2016-08-30 17:45 ` [PATCH v4 5/5] IMA: Demonstration code for kexec buffer passing Thiago Jung Bauermann
2016-08-30 17:45 ` Thiago Jung Bauermann
2016-09-07 13:51 ` [PATCH v4 0/5] kexec_file: Add buffer hand-over for the next kernel Eric W. Biederman
2016-09-07 13:51 ` Eric W. Biederman
2016-09-07 14:19 ` Eric W. Biederman
2016-09-07 14:19 ` Eric W. Biederman
2016-09-08 19:20 ` Thiago Jung Bauermann [this message]
2016-09-08 19:20 ` Thiago Jung Bauermann
2016-09-09 4:07 ` Eric W. Biederman
2016-09-09 4:07 ` Eric W. Biederman
2016-09-09 13:08 ` Mimi Zohar
2016-09-09 13:08 ` Mimi Zohar
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=3106532.NfQxgDJQ20@hactar \
--to=bauerman@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=bsingharora@gmail.com \
--cc=dyoung@redhat.com \
--cc=ebiederm@xmission.com \
--cc=erichte@linux.vnet.ibm.com \
--cc=kexec@lists.infradead.org \
--cc=linux-ima-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=stewart@linux.vnet.ibm.com \
--cc=vgoyal@redhat.com \
--cc=zohar@linux.vnet.ibm.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.