From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sumit Garg Date: Thu, 14 May 2020 11:35:34 +0000 Subject: Re: [PATCH v4 1/4] KEYS: trusted: Add generic trusted keys framework Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit List-Id: References: <1588758017-30426-1-git-send-email-sumit.garg@linaro.org> <1588758017-30426-2-git-send-email-sumit.garg@linaro.org> <07bb6080f8be9f6613f460e2d6e19f3d456e219c.camel@linux.intel.com> In-Reply-To: <07bb6080f8be9f6613f460e2d6e19f3d456e219c.camel@linux.intel.com> To: Jarkko Sakkinen Cc: "tee-dev @ lists . linaro . 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 , dhowells@redhat.com, linux-security-module@vger.kernel.org, "open list:ASYMMETRIC KEYS" , Markus Wamser , Casey Schaufler , linux-integrity@vger.kernel.org, Jens Wiklander , linux-arm-kernel , "Serge E. Hallyn" On Thu, 14 May 2020 at 05:55, Jarkko Sakkinen wrote: > > On Wed, 2020-05-06 at 15:10 +0530, Sumit Garg wrote: > > Current trusted keys framework is tightly coupled to use TPM device as > > an underlying implementation which makes it difficult for implementations > > like Trusted Execution Environment (TEE) etc. to provide trusked keys > > support in case platform doesn't posses a TPM device. > > > > So this patch tries to add generic trusted keys framework where underlying > > implemtations like TPM, TEE etc. could be easily plugged-in. > > > > Suggested-by: Jarkko Sakkinen > > Signed-off-by: Sumit Garg > > I tend to agree how this is implemented and could merge it as such. > > I'm just thinking if we could refine this patch in a way that instead of > copying TRUSTED_DEBUG macro we could just replace pr_info() statements > with pr_debug()? AFAIU, TRUSTED_DEBUG being a security sensitive operation is only meant to be used in development environments and should be strictly disabled in production environments. But it may not always be true with pr_debug() with CONFIG_DYNAMIC_DEBUG=y which allows the debug paths to be compiled into the kernel which can be enabled/disabled at runtime. IMO we should keep this TRUSTED_DEBUG macro, so that users are aware of its security sensitive nature and need to explicitly enable it to debug. -Sumit > > /Jarkko > 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=-3.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 CA49CC433E0 for ; Thu, 14 May 2020 11:23:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A22D4206A5 for ; Thu, 14 May 2020 11:23:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="AQB8AjMy" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726316AbgENLXt (ORCPT ); Thu, 14 May 2020 07:23:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34602 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726176AbgENLXt (ORCPT ); Thu, 14 May 2020 07:23:49 -0400 Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 62902C05BD43 for ; Thu, 14 May 2020 04:23:47 -0700 (PDT) Received: by mail-lf1-x142.google.com with SMTP id 82so797690lfh.2 for ; Thu, 14 May 2020 04:23:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=52Rzrrj4E2al2tTGlHFyR6M/8l4BjJi9pTbsEHvkafw=; b=AQB8AjMyAZSGOL4e97UU90oVl9kAMguV5p4dTDDqcw0/yek+GT5FWuN2tscAVlKFEs EGzg8HjoW6dtHzhFbCevirz+96qH21ZW9fHpy2kzigcrKVJlygWbNXwPaiOUs6uFh063 aPAdVZthuA7Y6Oqs1VLm4MDl2Ymqdb56dcWwjCBZ0og7DZpzl8xsqkqa05M1swjos7Gz BvCnthOJZ3OAhbZMPq0iz6CbKdHXINgpBnT6TT6KscyzM/JwxVG6ZXzKdHQmih4z9i43 mHHs4GZHjvk6LTACjAngtXARfd2tJBCvG7KpSeW1akMKIkbng2rYc0JDaLTV5N6BoPB4 oObw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=52Rzrrj4E2al2tTGlHFyR6M/8l4BjJi9pTbsEHvkafw=; b=RFwgbzpqzr0CMRT9O68WZrpG4PQNavL1JUnbHjKqKZCHK7qM9a68a9l+CSXWulIHCx xJaiGk/BNVO69yY8pU6F8nTKYG12HwTLMjpsQEh/RhIStO0q1InwDkoskdpZprEsrlAD xYpLZwtacVv0b8cFonixQCdJrT1JX03d7zkNq3x+aImAeIcxliWo5c7nIfoA12kqmbiG EArvFVjHjrZ90XequI/ipG1CDqF8vSMvHsb+BSH8weQSAfWtJvc6HZiOpfOuQT0eVg+m 0l4YHIdE8RFn7/8eUlr30gEbrXU0WzlM5v7KBjejqN+AV859qapgmaiAfIQNLYT94leU 4aVg== X-Gm-Message-State: AOAM530T7/LcLSgTeH3lrRCepn98z8GjhnDi6VT4yAu3DfuC6K2ie/L8 +HIuWjXFmhg4TAGFaoUwxAMNtdxIKDjXXGj2y/xv1Q== X-Google-Smtp-Source: ABdhPJyJHVIeFpsuP6hWyR4T3t3i5l95UvM1ck7qhqVExGI1lWc37GndFTYXCpQQGciey+GLFpqutzOT/FYhOL3syjg= X-Received: by 2002:ac2:44bb:: with SMTP id c27mr3095483lfm.40.1589455425658; Thu, 14 May 2020 04:23:45 -0700 (PDT) MIME-Version: 1.0 References: <1588758017-30426-1-git-send-email-sumit.garg@linaro.org> <1588758017-30426-2-git-send-email-sumit.garg@linaro.org> <07bb6080f8be9f6613f460e2d6e19f3d456e219c.camel@linux.intel.com> In-Reply-To: <07bb6080f8be9f6613f460e2d6e19f3d456e219c.camel@linux.intel.com> From: Sumit Garg Date: Thu, 14 May 2020 16:53:34 +0530 Message-ID: Subject: Re: [PATCH v4 1/4] KEYS: trusted: Add generic trusted keys framework To: Jarkko Sakkinen Cc: Mimi Zohar , James Bottomley , dhowells@redhat.com, Jens Wiklander , Jonathan Corbet , James Morris , "Serge E. Hallyn" , Casey Schaufler , Janne Karhunen , Daniel Thompson , Markus Wamser , "open list:ASYMMETRIC KEYS" , linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, Linux Doc Mailing List , Linux Kernel Mailing List , linux-arm-kernel , op-tee@lists.trustedfirmware.org, "tee-dev @ lists . linaro . org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 14 May 2020 at 05:55, Jarkko Sakkinen wrote: > > On Wed, 2020-05-06 at 15:10 +0530, Sumit Garg wrote: > > Current trusted keys framework is tightly coupled to use TPM device as > > an underlying implementation which makes it difficult for implementations > > like Trusted Execution Environment (TEE) etc. to provide trusked keys > > support in case platform doesn't posses a TPM device. > > > > So this patch tries to add generic trusted keys framework where underlying > > implemtations like TPM, TEE etc. could be easily plugged-in. > > > > Suggested-by: Jarkko Sakkinen > > Signed-off-by: Sumit Garg > > I tend to agree how this is implemented and could merge it as such. > > I'm just thinking if we could refine this patch in a way that instead of > copying TRUSTED_DEBUG macro we could just replace pr_info() statements > with pr_debug()? AFAIU, TRUSTED_DEBUG being a security sensitive operation is only meant to be used in development environments and should be strictly disabled in production environments. But it may not always be true with pr_debug() with CONFIG_DYNAMIC_DEBUG=y which allows the debug paths to be compiled into the kernel which can be enabled/disabled at runtime. IMO we should keep this TRUSTED_DEBUG macro, so that users are aware of its security sensitive nature and need to explicitly enable it to debug. -Sumit > > /Jarkko > 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=-3.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 76FB4C433E1 for ; Thu, 14 May 2020 11:23:53 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 4ADC5206A5 for ; Thu, 14 May 2020 11:23:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="uQHGQGQb"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="AQB8AjMy" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4ADC5206A5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-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=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=2gBEVH4tjDq3cmy727lQR7eilzVM1bnZg1PNqkEhFKs=; b=uQHGQGQbCq2WPw +Tp9A55GIBGhNfllw29CmIWIrj25jCG6Y7GpbVS9YuuPfCC1kyDulc0SkU0z3lk3v2SFCh8vaeoei f8F+hbDeN4wmzU/TalSy3AfcuEydC/h+7RLhZadOkq67VBIh9jRwLDQerw98G90QhlL18lYbSIL0v QUv6oo8nd0X8LLo1ioT4WQaXlJK9QP9DOFkEyFKzmrgScp7HCah1+xf+S/3xYwDLmzD9bchSjyWhT X+zd+Stokj0AsBOeAI1dnu4D0juHiTWXKBvXgbZiziY7TZrtBqVrvh9hTD6iyC2p03JnFfWnW3kGt gk8lhB1nnDfW6dOfYxoQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jZBxw-00058O-Uy; Thu, 14 May 2020 11:23:52 +0000 Received: from mail-lf1-x142.google.com ([2a00:1450:4864:20::142]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jZBxu-00057p-EZ for linux-arm-kernel@lists.infradead.org; Thu, 14 May 2020 11:23:51 +0000 Received: by mail-lf1-x142.google.com with SMTP id 188so2276785lfa.10 for ; Thu, 14 May 2020 04:23:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=52Rzrrj4E2al2tTGlHFyR6M/8l4BjJi9pTbsEHvkafw=; b=AQB8AjMyAZSGOL4e97UU90oVl9kAMguV5p4dTDDqcw0/yek+GT5FWuN2tscAVlKFEs EGzg8HjoW6dtHzhFbCevirz+96qH21ZW9fHpy2kzigcrKVJlygWbNXwPaiOUs6uFh063 aPAdVZthuA7Y6Oqs1VLm4MDl2Ymqdb56dcWwjCBZ0og7DZpzl8xsqkqa05M1swjos7Gz BvCnthOJZ3OAhbZMPq0iz6CbKdHXINgpBnT6TT6KscyzM/JwxVG6ZXzKdHQmih4z9i43 mHHs4GZHjvk6LTACjAngtXARfd2tJBCvG7KpSeW1akMKIkbng2rYc0JDaLTV5N6BoPB4 oObw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=52Rzrrj4E2al2tTGlHFyR6M/8l4BjJi9pTbsEHvkafw=; b=Sd9ymeBpxL7knvGCAv9+XK7D88oGPWek4+TzCNdpBOV9t78wDwTx0Y0jbjaK/2EvNc 1jUkohz5jA8ktIYdB2jAbXYyKOXNY4GZR9i9iBxN3S8SkmCSUJrA/bM8WERvAVlp5Vd1 tWIZLNoVeI6GcP7djXep10zQvf2E4l75kj0t9Vq2aq6gfinVMhO9WZdt8j7zGEuc2Kio EQOnw4jZO9WzLWA/5GXCfuW0HcOk+FEenGbaahyY5fB76GlBULkdZb37vtdL5Gfe8H0i 24D9B1Vp9IYtShHUVt/7UMLbR1cH/cpuA7jMGkOAUDe6Su3syMwaqb6fy15tzptcbHp8 7jpw== X-Gm-Message-State: AOAM531Z07rbvJqYIFTE5/j54IkSlvR7z2pFq1EuNHSpJE+vr7l72HKk 97YBJ2zvMOBRJvwbd65VhljwbrqXPiwiDp12k5mqCw== X-Google-Smtp-Source: ABdhPJyJHVIeFpsuP6hWyR4T3t3i5l95UvM1ck7qhqVExGI1lWc37GndFTYXCpQQGciey+GLFpqutzOT/FYhOL3syjg= X-Received: by 2002:ac2:44bb:: with SMTP id c27mr3095483lfm.40.1589455425658; Thu, 14 May 2020 04:23:45 -0700 (PDT) MIME-Version: 1.0 References: <1588758017-30426-1-git-send-email-sumit.garg@linaro.org> <1588758017-30426-2-git-send-email-sumit.garg@linaro.org> <07bb6080f8be9f6613f460e2d6e19f3d456e219c.camel@linux.intel.com> In-Reply-To: <07bb6080f8be9f6613f460e2d6e19f3d456e219c.camel@linux.intel.com> From: Sumit Garg Date: Thu, 14 May 2020 16:53:34 +0530 Message-ID: Subject: Re: [PATCH v4 1/4] KEYS: trusted: Add generic trusted keys framework To: Jarkko Sakkinen X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200514_042350_493423_72B9CB91 X-CRM114-Status: GOOD ( 16.08 ) 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: "tee-dev @ lists . linaro . 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 , dhowells@redhat.com, linux-security-module@vger.kernel.org, "open list:ASYMMETRIC KEYS" , 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+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 14 May 2020 at 05:55, Jarkko Sakkinen wrote: > > On Wed, 2020-05-06 at 15:10 +0530, Sumit Garg wrote: > > Current trusted keys framework is tightly coupled to use TPM device as > > an underlying implementation which makes it difficult for implementations > > like Trusted Execution Environment (TEE) etc. to provide trusked keys > > support in case platform doesn't posses a TPM device. > > > > So this patch tries to add generic trusted keys framework where underlying > > implemtations like TPM, TEE etc. could be easily plugged-in. > > > > Suggested-by: Jarkko Sakkinen > > Signed-off-by: Sumit Garg > > I tend to agree how this is implemented and could merge it as such. > > I'm just thinking if we could refine this patch in a way that instead of > copying TRUSTED_DEBUG macro we could just replace pr_info() statements > with pr_debug()? AFAIU, TRUSTED_DEBUG being a security sensitive operation is only meant to be used in development environments and should be strictly disabled in production environments. But it may not always be true with pr_debug() with CONFIG_DYNAMIC_DEBUG=y which allows the debug paths to be compiled into the kernel which can be enabled/disabled at runtime. IMO we should keep this TRUSTED_DEBUG macro, so that users are aware of its security sensitive nature and need to explicitly enable it to debug. -Sumit > > /Jarkko > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel