On Mon, 2023-12-04 at 08:53 -0500, James Bottomley wrote: > On Mon, 2023-12-04 at 08:43 -0500, Mimi Zohar wrote: > > On Mon, 2023-12-04 at 07:35 -0500, James Bottomley wrote: > > > On Mon, 2023-12-04 at 04:29 +0200, Jarkko Sakkinen wrote: > > > > On Sun Nov 26, 2023 at 5:05 PM EET, James Bottomley wrote: > > > > > On Sun, 2023-11-26 at 05:39 +0200, Jarkko Sakkinen wrote: > > > > > > One very obvious thing to fix there is the kconfig flag: > > > > > > > > > > > > 1. Its meaning and purpose is not documented to the commit > > > > > > message. What is it and what is its meaning and purpose. > > > > > > 2. TPM_BUS_SECURITY does not follow the naming convention of > > > > > > other TPM kconfig flags, and to add, "security" is way way > > > > > > too abstract word. Something like TCG_TPM_HMAC > > > > > > > > > > > > It should be renamed as TCG_TPM_ > > > > > > > > > > One question is do we still need this? Since my tree has moved > > > > > ahead, I also need the HMAC code for policy on keys and the > > > > > primary code for permanent parents. The only real performance > > > > > concern is for PCR extension (no-one really cares about the > > > > > speed of unseal or random), so a different possible way of > > > > > doing this is simply to CONFIG that one operation. > > > > > > > > I think so. > > > > > > > > Major distributions have started to ship with TPM2 sealed > > > > hardware drive encryption, based on LVM/LUKS2 partitioning setup. > > > > It is convenient enough that at least I prefer it over encrypted > > > > passphrase. > > > > > > > > Having this feature would add defence in depth to that. I could > > > > definitely see distributions adapting also to HMAC because now > > > > there is already too legit uses cases (ignoring the people who > > > > just enjoy configuring obscure things). > > > > > > > > So motivation has rised by a factor now, i.e. it makes sense now > > > > more as a "product" and not just research topic, given the use in > > > > the workstation, in addition to the data center. > > > > > > Sorry, miscommunication. By "this" I meant the config option not > > > the entire HMAC code. The proposal without it would be > > > unconditionally compile tpm2-sessions.c and do HMAC/encryption on > > > random and seal/unseal but gate the PCR HMAC via a compile or > > > runtime option so as not to degrade IMA performance if performance > > > were preferable to security. > > > > 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? Mimi
