From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752187AbdKUMaL (ORCPT ); Tue, 21 Nov 2017 07:30:11 -0500 Received: from mga09.intel.com ([134.134.136.24]:7634 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751684AbdKUMaJ (ORCPT ); Tue, 21 Nov 2017 07:30:09 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.44,432,1505804400"; d="scan'208";a="4244939" Date: Tue, 21 Nov 2017 14:30:06 +0200 From: Jarkko Sakkinen To: Javier Martinez Canillas Cc: linux-kernel@vger.kernel.org, Peter Huewe , Philip Tricca , Jason Gunthorpe , linux-integrity@vger.kernel.org, William Roberts Subject: Re: [RFC PATCH] tpm: don't return -EINVAL if TPM command validation fails Message-ID: <20171121123006.esr7yxs5lvorlfjf@linux.intel.com> References: <20171117100724.19257-1-javierm@redhat.com> <20171120231512.6wpqgcggfta3am7m@linux.intel.com> <7c148cf0-2403-55cf-1633-ff326d5c6f7b@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7c148cf0-2403-55cf-1633-ff326d5c6f7b@redhat.com> 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, Nov 21, 2017 at 10:07:34AM +0100, Javier Martinez Canillas wrote: > As mentioned, I think this should be documented. I guess most people > would see the in-kernel resource manager as a virtualized TPM, since > the "TSS TAB and Resource Manager Specification" [0] explains the RM > making an analogy with a virtual memory manager: > > "The Resource Manager (RM) manages the TPM context in a manner similar > to a virtual memory manager. It swaps objects, sessions, and sequences > in and out of the limited TPM memory as needed." A process in virtual memory has a different environment than code running on bare metal without page table, doesn't it? > And even your latest LPC presentation mention that the handles in the > in-kernel resource manager are virtualized [1]. > > And I disagree that it does not matter, since the same spec says: > > "This layer is mostly transparent to the upper layers of the TSS and is > not required." > > But returning -EINVAL instead of a proper TPM command response with a > TPM_RC_COMMAND_CODE code makes it not transparent to the upper layer. *mostly* > If the TPM spaces infrastructure is not compliant with the spec, then I > think that should also be documented. TPM specification is not a formal specification AFAIK. > > matters less than breaking the sandbox. > > > > Yes, sorry for that. It wasn't clear to me that there was a sandbox and my > lack of familiarity with the code was the reason why I posted as a RFC in > the first place. > > Do you agree with Jason's suggestion to send a synthesized TPM command in > the that the command isn't supported? Nope. /Jarkko