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. James
