[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