[RFC] IMA Log Snapshotting Design Proposal - network bandwidth

Ken Goldman kgold at linux.ibm.com
Wed Sep 6 13:20:35 PDT 2023



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.




More information about the kexec mailing list