From: Ken Goldman <kgold@linux.ibm.com>
To: Tushar Sugandhi <tusharsu@linux.microsoft.com>,
linux-integrity@vger.kernel.org, Mimi Zohar <zohar@linux.ibm.com>,
peterhuewe@gmx.de, Jarkko Sakkinen <jarkko@kernel.org>,
jgg@ziepe.ca, bhe@redhat.com, vgoyal@redhat.com,
Dave Young <dyoung@redhat.com>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
jmorris@namei.org, Paul Moore <paul@paul-moore.com>,
serge@hallyn.com,
James Bottomley <James.Bottomley@HansenPartnership.com>,
linux-security-module@vger.kernel.org
Cc: Tyler Hicks <tyhicks@linux.microsoft.com>,
Lakshmi Ramasubramanian <nramas@linux.microsoft.com>,
Sush Shringarputale <sushring@linux.microsoft.com>
Subject: Re: [RFC V2] IMA Log Snapshotting Design Proposal
Date: Tue, 31 Oct 2023 14:37:19 -0400 [thread overview]
Message-ID: <1f7bdb13-859e-46ce-b327-8043e7dbd598@linux.ibm.com> (raw)
In-Reply-To: <6c0c32d5-e636-2a0e-5bdf-538c904ceea3@linux.microsoft.com>
On 10/19/2023 2:49 PM, Tushar Sugandhi wrote:
> f. A new event, "snapshot_aggregate", will be computed and measured
> in the IMA log as part of this feature. It should help the
> remote-attestation client/service to benefit from the IMA log
> snapshot feature.
> The "snapshot_aggregate" event is described in more details in
> section "D.1 Snapshot Aggregate Event" below.
What is the use case for the snapshot aggregate? My thinking is:
1. The platform must retain the entire measurement list. Early
measurements can never be discarded because a new quote verifier
must receive the entire log starting at the first measurement.
In this case, isn't the snapshot aggregate redundant?
2. There is a disadvantage to redundant data. The verifier must support
this new event type. It receives this event and must validate the
aggregate against the snapshot-ed events. This is an attack surface.
The attacker can send an aggregate and snapshot-ed measurements that do
not match to exploit a flaw in the verifier.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Ken Goldman <kgold@linux.ibm.com>
To: Tushar Sugandhi <tusharsu@linux.microsoft.com>,
linux-integrity@vger.kernel.org, Mimi Zohar <zohar@linux.ibm.com>,
peterhuewe@gmx.de, Jarkko Sakkinen <jarkko@kernel.org>,
jgg@ziepe.ca, bhe@redhat.com, vgoyal@redhat.com,
Dave Young <dyoung@redhat.com>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
jmorris@namei.org, Paul Moore <paul@paul-moore.com>,
serge@hallyn.com,
James Bottomley <James.Bottomley@HansenPartnership.com>,
linux-security-module@vger.kernel.org
Cc: Tyler Hicks <tyhicks@linux.microsoft.com>,
Lakshmi Ramasubramanian <nramas@linux.microsoft.com>,
Sush Shringarputale <sushring@linux.microsoft.com>
Subject: Re: [RFC V2] IMA Log Snapshotting Design Proposal
Date: Tue, 31 Oct 2023 14:37:19 -0400 [thread overview]
Message-ID: <1f7bdb13-859e-46ce-b327-8043e7dbd598@linux.ibm.com> (raw)
In-Reply-To: <6c0c32d5-e636-2a0e-5bdf-538c904ceea3@linux.microsoft.com>
On 10/19/2023 2:49 PM, Tushar Sugandhi wrote:
> f. A new event, "snapshot_aggregate", will be computed and measured
> in the IMA log as part of this feature. It should help the
> remote-attestation client/service to benefit from the IMA log
> snapshot feature.
> The "snapshot_aggregate" event is described in more details in
> section "D.1 Snapshot Aggregate Event" below.
What is the use case for the snapshot aggregate? My thinking is:
1. The platform must retain the entire measurement list. Early
measurements can never be discarded because a new quote verifier
must receive the entire log starting at the first measurement.
In this case, isn't the snapshot aggregate redundant?
2. There is a disadvantage to redundant data. The verifier must support
this new event type. It receives this event and must validate the
aggregate against the snapshot-ed events. This is an attack surface.
The attacker can send an aggregate and snapshot-ed measurements that do
not match to exploit a flaw in the verifier.
next prev parent reply other threads:[~2023-10-31 18:41 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-19 18:49 [RFC V2] IMA Log Snapshotting Design Proposal Tushar Sugandhi
2023-10-19 18:49 ` Tushar Sugandhi
2023-10-31 18:37 ` Ken Goldman [this message]
2023-10-31 18:37 ` Ken Goldman
2023-11-13 18:14 ` Sush Shringarputale
2023-11-13 18:14 ` Sush Shringarputale
2023-10-31 19:15 ` Mimi Zohar
2023-10-31 19:15 ` Mimi Zohar
2023-11-16 22:28 ` Paul Moore
2023-11-16 22:28 ` Paul Moore
2023-11-22 1:01 ` Tushar Sugandhi
2023-11-22 1:01 ` Tushar Sugandhi
2023-11-22 1:18 ` Mimi Zohar
2023-11-22 1:18 ` Mimi Zohar
2023-11-22 4:27 ` Paul Moore
2023-11-22 4:27 ` Paul Moore
2023-11-22 13:18 ` Mimi Zohar
2023-11-22 13:18 ` Mimi Zohar
2023-11-22 14:22 ` Paul Moore
2023-11-22 14:22 ` Paul Moore
2023-11-27 17:07 ` Mimi Zohar
2023-11-27 17:07 ` Mimi Zohar
2023-11-27 22:16 ` Paul Moore
2023-11-27 22:16 ` Paul Moore
2023-11-28 12:09 ` Mimi Zohar
2023-11-28 12:09 ` Mimi Zohar
2023-11-29 1:06 ` Paul Moore
2023-11-29 1:06 ` Paul Moore
2023-11-29 2:07 ` Mimi Zohar
2023-11-29 2:07 ` Mimi Zohar
2024-01-06 23:27 ` Paul Moore
2024-01-06 23:27 ` Paul Moore
2024-01-07 12:58 ` Mimi Zohar
2024-01-07 12:58 ` Mimi Zohar
2024-01-08 2:58 ` Paul Moore
2024-01-08 2:58 ` Paul Moore
2024-01-08 11:48 ` Mimi Zohar
2024-01-08 11:48 ` Mimi Zohar
2024-01-08 17:15 ` Paul Moore
2024-01-08 17:15 ` Paul Moore
2023-12-20 22:13 ` Ken Goldman
2023-12-20 22:13 ` Ken Goldman
2024-01-06 23:44 ` Paul Moore
2024-01-06 23:44 ` Paul Moore
2023-11-13 18:59 ` Stefan Berger
2023-11-13 18:59 ` Stefan Berger
2023-11-14 18:36 ` Sush Shringarputale
2023-11-14 18:36 ` Sush Shringarputale
2023-11-14 18:58 ` Stefan Berger
2023-11-14 18:58 ` Stefan Berger
2023-11-16 22:07 ` Paul Moore
2023-11-16 22:07 ` Paul Moore
2023-11-16 22:41 ` Stefan Berger
2023-11-16 22:41 ` Stefan Berger
2023-11-16 22:56 ` Paul Moore
2023-11-16 22:56 ` Paul Moore
2023-11-17 22:41 ` Sush Shringarputale
2023-11-17 22:41 ` Sush Shringarputale
2023-11-20 20:03 ` Tushar Sugandhi
2023-11-20 20:03 ` Tushar Sugandhi
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=1f7bdb13-859e-46ce-b327-8043e7dbd598@linux.ibm.com \
--to=kgold@linux.ibm.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=bhe@redhat.com \
--cc=dyoung@redhat.com \
--cc=jarkko@kernel.org \
--cc=jgg@ziepe.ca \
--cc=jmorris@namei.org \
--cc=kexec@lists.infradead.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=nramas@linux.microsoft.com \
--cc=paul@paul-moore.com \
--cc=peterhuewe@gmx.de \
--cc=serge@hallyn.com \
--cc=sushring@linux.microsoft.com \
--cc=tusharsu@linux.microsoft.com \
--cc=tyhicks@linux.microsoft.com \
--cc=vgoyal@redhat.com \
--cc=zohar@linux.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.