On Tue, Oct 24, 2017 at 10:05:20PM +0530, PrasannaKumar Muralidharan wrote: > > 1. Every user in the kernel is using TPM_ANY_NUM, which means there are > > no other users. > > Completely agree that there is no in kernel users yet. And should never be. It's a bogus parameter that makes no sense. > > 2. Moving struct tpm_rng to the TPM client is architecturally > > uacceptable. > > As there was no response to the patch there is no way to know whether > it is acceptable or not. I like the idea of removing the tpm rng driver as discussed in other emails in this thread. > > 3. Using zero deos not give you any better guarantees on anything than > > just using TPM_ANY_NUM. > > Chip id is used, not zero. Sorry I misread the patch first time. Anyway it's not any kind of ID to be trusted. > > Why this patch is not CC'd to linux-integrity? It modifies the TPM > > driver. And in the worst way. > > TPM list is moderated and the moderator has not approved it yet. > get_maintainer script did not say about linux-integrity mailing list. > > It could be doing things in worst way but it is not known until some > one says. If no one tells it is the case I don't think it is possible > to fix. Which is what happened. Understood. We've moved to linux-integrity@xxxxxxxxxxxxxxx. MAINTAINERS update is in the queue for the next kernel release. > > Implementing the ideas that Jason explained is the senseful way to > > get stable access. modules.dep makes sure that the modules are loaded > > in the correct order. > > If that is sensible then it is the way to go. > > There must be a reason to believe what is sensible and what is not. > Looks like this RFC has helped in judging that. > > Regards, > PrasannaKumar Would you be interested to work on patch set that would remove the existing tpm rng driver and make the TPM driver the customer? It's not that far away from the work you've been doing already. /Jarkko
