Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-ID: <1575923513.31378.22.camel@linux.ibm.com>
Subject: Re: One question about trusted key of keyring in Linux kernel.
From:   James Bottomley <jejb@linux.ibm.com>
To:     Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc:     "Zhao, Shirley" <shirley.zhao@intel.com>,
        Mimi Zohar <zohar@linux.ibm.com>,
        Jonathan Corbet <corbet@lwn.net>,
        "linux-integrity@vger.kernel.org" <linux-integrity@vger.kernel.org>,
        "keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "'Mauro Carvalho Chehab'" <mchehab+samsung@kernel.org>,
        "Zhu, Bing" <bing.zhu@intel.com>,
        "Chen, Luhai" <luhai.chen@intel.com>
Date:   Mon, 09 Dec 2019 12:31:53 -0800
In-Reply-To: <20191209194715.GD19243@linux.intel.com>
References: <A888B25CD99C1141B7C254171A953E8E49096521@shsmsx102.ccr.corp.intel.com>
         <1575057916.6220.7.camel@linux.ibm.com>
         <A888B25CD99C1141B7C254171A953E8E4909BA3B@shsmsx102.ccr.corp.intel.com>
         <1575260220.4080.17.camel@linux.ibm.com>
         <A888B25CD99C1141B7C254171A953E8E4909D360@shsmsx102.ccr.corp.intel.com>
         <1575267453.4080.26.camel@linux.ibm.com>
         <A888B25CD99C1141B7C254171A953E8E4909E381@shsmsx102.ccr.corp.intel.com>
         <1575269075.4080.31.camel@linux.ibm.com>
         <A888B25CD99C1141B7C254171A953E8E4909E399@shsmsx102.ccr.corp.intel.com>
         <1575312932.24227.13.camel@linux.ibm.com>
         <20191209194715.GD19243@linux.intel.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, 2019-12-09 at 21:47 +0200, Jarkko Sakkinen wrote:
> On Mon, Dec 02, 2019 at 10:55:32AM -0800, James Bottomley wrote:
> > blob but it looks like we need to fix the API.  I suppose the good
> > news is given this failure that we have the opportunity to rewrite
> > the API since no-one else can have used it for anything because of
> > this.  The
> 
> I did successfully run this test when I wrote it 5 years ago:
> 
> https://github.com/jsakkine-intel/tpm2-scripts/blob/master/keyctl-smo
> ke.sh
> 
> Given that there is API a way must be found that backwards
> compatibility
> is not broken. New format is fine but it must co-exist.

The old API is unsupportable in the combination of policy + auth as I
already explained.  The kernel doesn't have access to the nonces to
generate the HMAC because the session was created by the user and the
API has no way to pass them in (plus passing them in would be a huge
security failure if we tried).  Given that Shirley appears to be the
first person ever to try this, I don't think the old API has grown any
policy users so its safe to remove it.  If we get a complaint, we can
discuss adding it back.

James