On Thu, Oct 26, 2017 at 03:42:27PM +0000, alexander.stef...@infineon.com wrote: > As far as I know, the kernel itself is not using any of the affected > functionalities, so there is no need for an immediate mitigation > within the kernel. But I'd like to hear about how similar issues were > handled in the past. I can think of multiple severe security issues, > for example in BIOS implementations, but I cannot recall ever hearing > about the kernel refusing to boot on such machines or even do so much > as print a warning about that vulnerability.
Hmm.. trusted key with parent other than a primary key? > > Alexander stated the following things about FW updates (Alexander, > > please correct me if I state something incorrectly or if you have > > something to add): > > > > * FW update can be constructed either in a way that the keys in the > > NVRAM are not cleared or in a way that they are cleared. > > Correct. But as far as I know, the updates that were already published > for this issue do not delete any of the keys. And I do not think that > this would be a good idea. After all, the applications still might > need access to their key to decrypt their data and reencrypt it with a > safe key after applying the update. Right, obviously :-) > > * FW update cannot be directly applied to the TPM but must come as > > part of the firmware update from the vendor. > > Yes, starting the upgrade process is guarded by > platformAuth/platformPolicy (in the case of TPM2), so the platform > vendor needs to be involved. And you want them to be involved, since > they need to make sure that their system still works with the updated > TPM. I'm not sure whether platform vendors do that for TPMs, but for > wireless cards whitelisting in the BIOS is common, and you do not want > your machine refusing to boot just because the BIOS does not recognize > your TPM's firmware version anymore (as a simple example). > > > I proposed the following as an alternative: > > > > * Print a message to the klog (which log level would be appropriate?). > > * Possibly sleep for few seconds. Is this a good idea? > > I'd be okay with that, but ideally we'd have some kind of > agreement/history of how to handle similar security issues in hardware > components in general. Implementing a special case just for this TPM > vulnerability does not seem like the right thing to do, especially > when the kernel itself is not affected (and thus the whole machine > might not be affected for the way that it is used). We do not want to > confuse users or make them expect similar warnings in the future, when > we might have no intention of providing them. > > > While writing this email yet another alternative popped into my mind: > > what if we allow only in-kernel use but disallow the use of /dev/tpm0? > > You could still use trusted keys. > > > > Here are all the ideas that I have and I am open for better > > alternatives. > > > > /Jarkko > > Alexander Thank you for elaborating this further! /Jarkko
