On Thu, Aug 24, 2017 at 10:37:14AM +0200, Alexander Steffen wrote: > When one of the commands during the auto_startup sequences does not return > TPM_RC_SUCCESS, tpm_chip_register misleadingly returns ENODEV, even though > a TPM device is definitely present. > > An error response during those sequences is indeed unexpected, so to > prevent subsequent errors, the kernel should not make use of the TPM > device. But user space applications still might be able to communicate with > the TPM, so they can be used to further diagnose and/or fix the problem. To > allow this, with this patch the device is still exported to user space, > even if a TPM error code has been received, but the kernel itself will not > be allowed to use the device for anything. > > This is not a hypothetical scenario, but there are devices in the wild that > show this behavior. With this fix, those devices can be recovered from > their failed state. > > Signed-off-by: Alexander Steffen <alexander.stef...@infineon.com>
I can understand the benefits but you could make the same argument for any class devices that kernel handles. I don't think it is that common to let user space access malfunctioning devices. Adding linux-security-module. PS. You should have in *all* patches that you don't tag as RFC have linux-ker...@vger.kernel.org. Now you have it in *none* of your patches. When you don't have RFC you are saying out loud that this is production ready code that should be included to the mainline kernel. PPS. This patch set should be obviously RFC. It's avery questionable and intrusive change. That's why I didn't include linux-kernel. /Jarkko ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ tpmdd-devel mailing list tpmdd-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
