From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932184AbdJXSYD (ORCPT ); Tue, 24 Oct 2017 14:24:03 -0400 Received: from mga01.intel.com ([192.55.52.88]:30163 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750897AbdJXSX7 (ORCPT ); Tue, 24 Oct 2017 14:23:59 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.43,428,1503385200"; d="scan'208";a="166552495" Date: Tue, 24 Oct 2017 20:22:35 +0200 From: Jarkko Sakkinen To: PrasannaKumar Muralidharan Cc: Jason Gunthorpe , Stefan Berger , linux-integrity@vger.kernel.org, David Howells , Herbert Xu , "open list:INTEGRITY MEASUREMENT ARCHITECTURE IMA" , Dmitry Kasatkin , open list , linux-security-module@vger.kernel.org, "moderated list:TPM DEVICE DRIVER" , "open list:KEYS-TRUSTED" , "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , James Morris , Matt Mackall , "open list:INTEGRITY MEASUREMENT ARCHITECTURE IMA" , David Safford , Mimi Zohar , "Serge E. Hallyn" Subject: Re: [tpmdd-devel] [PATCH] tpm: remove chip_num parameter from in-kernel API Message-ID: <20171024182235.d7b3oajc5zcjs57v@linux.intel.com> References: <20171023123817.18559-1-jarkko.sakkinen@linux.intel.com> <20171023163139.GA17394@obsidianresearch.com> <20171024154440.3jeupmus43jcgbbz@linux.intel.com> <20171024162359.tf5xulhlhokmuxh5@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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@vger.kernel.org. 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