On Mon, 2023-12-04 at 09:10 -0500, Mimi Zohar wrote: > On Mon, 2023-12-04 at 09:02 -0500, James Bottomley wrote: > > On Mon, 2023-12-04 at 08:59 -0500, Mimi Zohar wrote: > > > On Mon, 2023-12-04 at 08:53 -0500, James Bottomley wrote: > > > > On Mon, 2023-12-04 at 08:43 -0500, Mimi Zohar wrote: > > [...] > > > > > Is there a way of not degrading IMA performance without > > > > > disabling > > > > > HMAC encryption/decryption? > > > > > > > > Well, perhaps we should measure it. My operating assumption, > > > > since extend is a simple hash, is that most of the latency of > > > > extend is actually in the LPC (or i2c or whatever) bus round > > > > trip. To do HMAC, you have to have a session, which adds an > > > > extra command and thus doubles the round trip. > > > > > > Agreed getting some statistics would be beneficial. Instead of > > > creating a session for each IMA extend, would it be possible to > > > estable a session once and re-use it? > > > > Not really. Sessions are fairly cheap to establish, so there's not > > much work the TPM has to do, so context save/restore would still > > have the same doubling of the bus round trip. Keeping a session > > permanently in the TPM would avoid the second round trip but be > > visible to all the users and highly undesirable (would impact the > > number of sessions they could create). > > Ignoring the "highly undersirable" aspsect, is there a way of > limiting visibility (and of course usage) of the "session permanently > in the TPM" to just IMA? In theory, yes, but we'd have to filter the session area of every command plus inspect commands which take sessions as parameters. That's a lot of work which would have to be done by an infrastructure that doesn't fully exist (we already snoop the sessions in tpm space handling, so we can filter the session areas there; we'd have to add filtering on commands which take sessions). But nothing can really get around the problem that commands can take three sessions and on most TPMs that's also the maximum size of the session volatile area, so we'd break any user space application that uses more than two sessions. James
