From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 449BEC433E7 for ; Tue, 13 Oct 2020 13:42:25 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C220520659 for ; Tue, 13 Oct 2020 13:42:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="3C5QHyXo"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="iEP+Ktkx" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C220520659 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=2WgoyMmOEuGOd1l4oBv0ZluFaW3R0l2wujBmoChun38=; b=3C5QHyXolP+MDYs5veMYTW3pr IWhliObYT9xs1dCVpS9YcDxnjsJO1emrKCtyi2AQp//9BKHyy24aOu79hPheuhzPCE7yE2t/8YVMS 119o7Y9qgVWQhwHi0y/Enmg0OWjB0ZNrFOaveP4A1UXxtUnR47CuXRIkbsoM4NxAiKyE6+61AcZIi gG1jF0dnC7SB+yQbUv5yYjLX2S67cxSqEdHVjVh69vQqz9hkF7M4GQ0k6bsflH3nuo3T4WdwQ6W16 jM3hab1ynoAKk6u7at6bM7rth+WQtWfHdUSfJemcnggfncBU4EeJT6mdtM0ZGI3hN7DewhxuDgzg4 Cm98dEccA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kSKXw-00086V-7O; Tue, 13 Oct 2020 13:40:56 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kSKXr-00084r-Tq for linux-arm-kernel@lists.infradead.org; Tue, 13 Oct 2020 13:40:52 +0000 Received: from localhost (83-245-197-237.elisa-laajakaista.fi [83.245.197.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5114024741; Tue, 13 Oct 2020 13:40:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1602596450; bh=hMKks0yH+1QbT8lmw2IcB9FvKt0uw8hZHVUF20d9isU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=iEP+KtkxdbveqHc3o6dc0NabtkgQBAMQRm6bRQ2wdx9i0idUyeoN5bGhVU9LshPhp RQ63GxGtL7rGZLClYXAzipFBusI5YRWl3Ei/5GCzmB4WQdmknstsXe4e0k9JPY8ebc MIveOdrgpZSUwYYlnCVuFPoWuCxl9brA4QH81e+I= Date: Tue, 13 Oct 2020 16:40:48 +0300 From: Jarkko Sakkinen To: Sumit Garg Subject: Re: [PATCH v7 4/4] MAINTAINERS: Add entry for TEE based Trusted Keys Message-ID: <20201013134048.GA147135@kernel.org> References: <1602065268-26017-1-git-send-email-sumit.garg@linaro.org> <1602065268-26017-5-git-send-email-sumit.garg@linaro.org> <20201013022157.GA47751@linux.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201013_094052_104984_550C82AD X-CRM114-Status: GOOD ( 32.98 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-security-module@vger.kernel.org, Daniel Thompson , op-tee@lists.trustedfirmware.org, Jonathan Corbet , James Bottomley , Janne Karhunen , Linux Doc Mailing List , James Morris , Mimi Zohar , Linux Kernel Mailing List , David Howells , Luke Hinds , "open list:ASYMMETRIC KEYS" , Jarkko Sakkinen , Markus Wamser , Casey Schaufler , linux-integrity@vger.kernel.org, Jens Wiklander , linux-arm-kernel , "Serge E. Hallyn" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Oct 13, 2020 at 04:58:47PM +0530, Sumit Garg wrote: > On Tue, 13 Oct 2020 at 07:52, Jarkko Sakkinen > wrote: > > > > On Wed, Oct 07, 2020 at 03:37:48PM +0530, Sumit Garg wrote: > > > Add MAINTAINERS entry for TEE based Trusted Keys framework. > > > > > > Signed-off-by: Sumit Garg > > > Acked-by: Jarkko Sakkinen > > > --- > > > MAINTAINERS | 8 ++++++++ > > > 1 file changed, 8 insertions(+) > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > index 48aff80..eb3d889 100644 > > > --- a/MAINTAINERS > > > +++ b/MAINTAINERS > > > @@ -9663,6 +9663,14 @@ F: include/keys/trusted-type.h > > > F: include/keys/trusted_tpm.h > > > F: security/keys/trusted-keys/ > > > > > > +KEYS-TRUSTED-TEE > > > +M: Sumit Garg > > > +L: linux-integrity@vger.kernel.org > > > +L: keyrings@vger.kernel.org > > > +S: Supported > > > +F: include/keys/trusted_tee.h > > > +F: security/keys/trusted-keys/trusted_tee.c > > > + > > > KEYS/KEYRINGS > > > M: David Howells > > > M: Jarkko Sakkinen > > > -- > > > 2.7.4 > > > > I'm sorry but I think I have changed my mind on this. This has been > > spinning for a while and sometimes conclusions change over the time. > > > > I don't think that we really need a separate subsystem tag. > > I don't see it as a separate subsystem but rather a kind of underlying > trust source (TEE) driver plugged into existing trusted keys > subsystem. We could relate it to the RNG subsystem as well where there > is a subsystem maintainer and specific driver maintainers. > > IMO, having a dedicated entry like this brings clarity in maintenance > and in future we may have more trust sources like this added where > everyone may not have access to all the trust sources to test. More entries pointing to the exact same stuff does not necessarily mean clarity in my books. > > I'd be for a > > new M-entry or R-entry to the existing subsystem tag. It's essential to > > have ack from someone with ARM and TEE knowledge but this way too heavy > > for the purpose. > > If you still think otherwise then I am fine with a new M-entry for > existing trusted keys subsystem as well. Adding a M-entry does makes sense because trusted keys backends can be based on various technologies and standard. It's a different in that sense than lets say a TPM hardware driver. > > I also see it the most manageable if the trusted keys PR's come from a > > single source. > > I echo here with you to have a single source for trusted keys PR's > irrespective of whether we go with a separate trust source entry or > update existing subsystem entry. > > -Sumit And I echo that oviously if there is someone to say the final ack about TEE, I will require that as the minimum to ever pick any of those changes :-) I would resolve this with just the M-entry, and we can *later on* restructure, if there is a need for that. These things are not sealed to stone. /Jarkko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel