All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ken Goldman <kgold@linux.ibm.com>
To: Tushar Sugandhi <tusharsu@linux.microsoft.com>,
	Sush Shringarputale <sushring@linux.microsoft.com>,
	linux-integrity@vger.kernel.org, zohar@linux.ibm.com,
	peterhuewe@gmx.de, jarkko@kernel.org, jgg@ziepe.ca,
	bhe@redhat.com, vgoyal@redhat.com, dyoung@redhat.com,
	kexec@lists.infradead.org, jmorris@namei.org,
	Paul Moore <paul@paul-moore.com>,
	serge@hallyn.com
Cc: code@tyhicks.com, nramas@linux.microsoft.com,
	linux-security-module@vger.kernel.org
Subject: Re: [RFC] IMA Log Snapshotting Design Proposal - network bandwidth
Date: Wed, 6 Sep 2023 16:20:35 -0400	[thread overview]
Message-ID: <696e8be1-ad31-4ffd-711d-6fb5ce54fbd4@linux.ibm.com> (raw)
In-Reply-To: <5ce32966-c8c5-adc4-8b9e-f8300b266a61@linux.microsoft.com>



On 9/1/2023 5:20 PM, Tushar Sugandhi wrote:
> Thanks a lot Ken for looking at the proposal, and sharing your thoughts.
> 
> On 8/30/23 11:06, Ken Goldman wrote:
>>
>>
>> On 8/1/2023 3:12 PM, Sush Shringarputale wrote:
>>> In addition, a large IMA log can add pressure on the network 
>>> bandwidth when
>>> the attestation client sends it to remote-attestation-service.
>>
>> I would not worry too much about network bandwidth.
> Our bandwidth concerns are about scaled out system.
> 
> When IMA log size increases in the range of megabytes, and when the
> number of client devices increases, it makes an impact on the overall
> network bandwidth.

It should not, because the client only sends new measurements.  It only 
sends the entire list once per boot.

Does a megabyte matter in a modern network? As for overall performance,
a megabyte may take 10 msec, while the TPM quote could take 1000 msec, 
and verifier hash and asymmetric signature checks are also slower.

> 
>>
>> 1. Every solution eventually realizes that sending the entire log each 
>> time hurts performance.  The verifier will ask the attestor, "give me 
>> everything since record n", and the number of new entries approaches 
>> zero.
>>
> Completely agreed. IMA log snapshotting (this proposed feature) is a
> solution in that direction.

Does snapshotting matter?  The first time, the attester sends the entire 
log, whether part is snapshotted or not.  Same with incremental attestation.

I don't understand how snapshotting would have any affect on network 
traffic.


_______________________________________________
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>,
	Sush Shringarputale <sushring@linux.microsoft.com>,
	linux-integrity@vger.kernel.org, zohar@linux.ibm.com,
	peterhuewe@gmx.de, jarkko@kernel.org, jgg@ziepe.ca,
	bhe@redhat.com, vgoyal@redhat.com, dyoung@redhat.com,
	kexec@lists.infradead.org, jmorris@namei.org,
	Paul Moore <paul@paul-moore.com>,
	serge@hallyn.com
Cc: code@tyhicks.com, nramas@linux.microsoft.com,
	linux-security-module@vger.kernel.org
Subject: Re: [RFC] IMA Log Snapshotting Design Proposal - network bandwidth
Date: Wed, 6 Sep 2023 16:20:35 -0400	[thread overview]
Message-ID: <696e8be1-ad31-4ffd-711d-6fb5ce54fbd4@linux.ibm.com> (raw)
In-Reply-To: <5ce32966-c8c5-adc4-8b9e-f8300b266a61@linux.microsoft.com>



On 9/1/2023 5:20 PM, Tushar Sugandhi wrote:
> Thanks a lot Ken for looking at the proposal, and sharing your thoughts.
> 
> On 8/30/23 11:06, Ken Goldman wrote:
>>
>>
>> On 8/1/2023 3:12 PM, Sush Shringarputale wrote:
>>> In addition, a large IMA log can add pressure on the network 
>>> bandwidth when
>>> the attestation client sends it to remote-attestation-service.
>>
>> I would not worry too much about network bandwidth.
> Our bandwidth concerns are about scaled out system.
> 
> When IMA log size increases in the range of megabytes, and when the
> number of client devices increases, it makes an impact on the overall
> network bandwidth.

It should not, because the client only sends new measurements.  It only 
sends the entire list once per boot.

Does a megabyte matter in a modern network? As for overall performance,
a megabyte may take 10 msec, while the TPM quote could take 1000 msec, 
and verifier hash and asymmetric signature checks are also slower.

> 
>>
>> 1. Every solution eventually realizes that sending the entire log each 
>> time hurts performance.  The verifier will ask the attestor, "give me 
>> everything since record n", and the number of new entries approaches 
>> zero.
>>
> Completely agreed. IMA log snapshotting (this proposed feature) is a
> solution in that direction.

Does snapshotting matter?  The first time, the attester sends the entire 
log, whether part is snapshotted or not.  Same with incremental attestation.

I don't understand how snapshotting would have any affect on network 
traffic.


  reply	other threads:[~2023-09-06 20:21 UTC|newest]

Thread overview: 104+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-01 19:12 [RFC] IMA Log Snapshotting Design Proposal Sush Shringarputale
2023-08-01 19:12 ` Sush Shringarputale
2023-08-01 21:21 ` James Bottomley
2023-08-01 21:21   ` James Bottomley
2023-08-07 22:49   ` Stefan Berger
2023-08-07 22:49     ` Stefan Berger
2023-08-08 12:35     ` James Bottomley
2023-08-08 12:35       ` James Bottomley
2023-08-08 13:31       ` Stefan Berger
2023-08-08 13:31         ` Stefan Berger
2023-08-08 18:26         ` James Bottomley
2023-08-08 18:26           ` James Bottomley
2023-08-08 20:09           ` Stefan Berger
2023-08-08 20:09             ` Stefan Berger
2023-08-08 21:41             ` James Bottomley
2023-08-08 21:41               ` James Bottomley
2023-08-10  4:43               ` Tushar Sugandhi
2023-08-10  4:43                 ` Tushar Sugandhi
2023-08-10 11:43                 ` James Bottomley
2023-08-10 11:43                   ` James Bottomley
2023-08-11 15:48                   ` Tushar Sugandhi
2023-08-11 15:48                     ` Tushar Sugandhi
2023-08-10  4:31           ` Tushar Sugandhi
2023-08-10  4:31             ` Tushar Sugandhi
2023-08-10  4:29         ` Tushar Sugandhi
2023-08-10  4:29           ` Tushar Sugandhi
2023-08-10  1:23       ` Tushar Sugandhi
2023-08-10  1:23         ` Tushar Sugandhi
2023-08-10  1:15     ` Tushar Sugandhi
2023-08-10  1:15       ` Tushar Sugandhi
2023-08-10 14:12       ` Stefan Berger
2023-08-10 14:12         ` Stefan Berger
2023-08-11 15:57         ` Tushar Sugandhi
2023-08-11 15:57           ` Tushar Sugandhi
2023-08-11 18:16           ` Stefan Berger
2023-08-11 18:16             ` Stefan Berger
2023-08-10  1:03   ` Tushar Sugandhi
2023-08-10  1:03     ` Tushar Sugandhi
2023-08-11 13:14 ` Mimi Zohar
2023-08-11 13:14   ` Mimi Zohar
2023-08-14 21:42   ` Sush Shringarputale
2023-08-14 21:42     ` Sush Shringarputale
2023-08-14 22:02     ` Mimi Zohar
2023-08-14 22:02       ` Mimi Zohar
2023-08-21 22:05       ` Sush Shringarputale
2023-08-21 22:05         ` Sush Shringarputale
2023-08-21 23:07         ` Mimi Zohar
2023-08-21 23:07           ` Mimi Zohar
2023-08-29 19:34           ` Paul Moore
2023-08-29 19:34             ` Paul Moore
2023-08-29 21:03             ` Mimi Zohar
2023-08-29 21:03               ` Mimi Zohar
2023-08-29 21:30               ` Paul Moore
2023-08-29 21:30                 ` Paul Moore
2023-08-29 21:54                 ` Mimi Zohar
2023-08-29 21:54                   ` Mimi Zohar
2023-08-29 23:15                   ` Paul Moore
2023-08-29 23:15                     ` Paul Moore
2023-08-30 20:25                     ` Mimi Zohar
2023-08-30 20:25                       ` Mimi Zohar
2023-08-30 20:47                       ` Paul Moore
2023-08-30 20:47                         ` Paul Moore
2023-08-30 21:50                         ` Mimi Zohar
2023-08-30 21:50                           ` Mimi Zohar
2023-08-30 22:21                           ` Paul Moore
2023-08-30 22:21                             ` Paul Moore
2023-08-30 22:23                             ` Paul Moore
2023-08-30 22:23                               ` Paul Moore
2023-08-30 23:06                               ` Mimi Zohar
2023-08-30 23:06                                 ` Mimi Zohar
2023-08-30 23:22                                 ` Paul Moore
2023-08-30 23:22                                   ` Paul Moore
2023-08-31 14:01                                   ` Mimi Zohar
2023-08-31 14:01                                     ` Mimi Zohar
2023-08-31 14:43                                     ` Paul Moore
2023-08-31 14:43                                       ` Paul Moore
2023-08-31 16:46                                   ` Dr. Greg
2023-08-31 16:46                                     ` Dr. Greg
2023-08-31 17:56                                     ` Paul Moore
2023-08-31 17:56                                       ` Paul Moore
2023-08-30 18:06 ` [RFC] IMA Log Snapshotting Design Proposal - network bandwidth Ken Goldman
2023-08-30 18:06   ` Ken Goldman
2023-09-01 21:20   ` Tushar Sugandhi
2023-09-01 21:20     ` Tushar Sugandhi
2023-09-06 20:20     ` Ken Goldman [this message]
2023-09-06 20:20       ` Ken Goldman
2023-09-07 20:40       ` Paul Moore
2023-09-07 20:40         ` Paul Moore
2023-08-30 18:12 ` [RFC] IMA Log Snapshotting Design Proposal - aggregate Ken Goldman
2023-08-30 18:12   ` Ken Goldman
2023-09-01 22:06   ` Tushar Sugandhi
2023-09-01 22:06     ` Tushar Sugandhi
2023-09-06 20:49     ` Ken Goldman
2023-09-06 20:49       ` Ken Goldman
2023-09-07 21:02       ` Paul Moore
2023-09-07 21:02         ` Paul Moore
2023-08-30 19:12 ` [RFC] IMA Log Snapshotting Design Proposal - unseal Ken Goldman
2023-08-30 19:12   ` Ken Goldman
2023-08-31 15:54   ` Dr. Greg
2023-08-31 15:54     ` Dr. Greg
2023-09-01 21:22   ` Tushar Sugandhi
2023-09-01 21:22     ` Tushar Sugandhi
2023-09-06 20:13     ` Ken Goldman
2023-09-06 20:13       ` Ken Goldman

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=696e8be1-ad31-4ffd-711d-6fb5ce54fbd4@linux.ibm.com \
    --to=kgold@linux.ibm.com \
    --cc=bhe@redhat.com \
    --cc=code@tyhicks.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=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.