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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id A1BADCE7A95 for ; Mon, 25 Sep 2023 15:23:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:References:To:From:Subject: Cc:Message-Id:Date:Mime-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ZPtwYX7ukzv5XmibOdY3GHcX7ntvRhXY34MvJEtjSWA=; b=KaC1J8QFdLlDlU kQzNFOhXd5h6qtMeSz4PcUZTQGptBwOyv/wuktK1O3S/t572INZoNRJldBjVJkbPzHAbEa5ymKqn8 U2okCRR3kCIYjT+tpn2likqeXL72/0VF3UqQHP3L+pqgSasZqUy6J7nrFGDM4NIPcQ2IAjuY5Mmke KUCn16LhXpexaupdG6BZGsRfIz3GfNZPpdBvZZ7i4XKJLIOHCulWH1Ck7ZmexCyA7isPQfrSsbqwn Gj2V6z7xOw12GQStlu8OqThRvB5Ms6mWDrwjO558rM/KQhnB2HhotPVdZSgGTbKsVB+r39SDNfjxw 3GOMNPUhH0/kVgsKCmsA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qknPx-00EXZd-2b; Mon, 25 Sep 2023 15:22:37 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qknPv-00EXYL-17 for linux-arm-kernel@lists.infradead.org; Mon, 25 Sep 2023 15:22:36 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 7F8476115A; Mon, 25 Sep 2023 15:22:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8F12DC433C8; Mon, 25 Sep 2023 15:22:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1695655351; bh=OGt2FOw6lDFFBJRltNV7eb25Y3RCJfPYVc/8wsDj+lM=; h=Date:Cc:Subject:From:To:References:In-Reply-To:From; b=Kp0VVt1IVmvLWEfHcZ2kGDvXU/kqTSlU+zkPCXYtz6OOHZKhyu9V5NSp0G4CcW036 DQ9LCiRXD6Q490pl7u8169h7tTEUAz8V7ziRXZiOnxF5dDnpKDrQj68Gjg0adng4T5 EC3+inaGcrSbVlkKIJs09PWUwziCRokB4AboyUs2UgQ2pt7Zy2tOwb59ADnu4WpGap yRdxENwoFnqspD1+SNBWaf1kvwgaAh2yycGM8qQMtVXclYdN2nIeGugErrwJvR4YEl H9OHYREey3oOXKbuXZV2mFLTFooU8OLOf/hOR2Asgxbi05opItQVsGdjANQ69Zqjb3 L4QCoe2YqHFVQ== Mime-Version: 1.0 Date: Mon, 25 Sep 2023 18:22:22 +0300 Message-Id: Cc: "Shawn Guo" , "Jonathan Corbet" , "Sascha Hauer" , "Pengutronix Kernel Team" , "Fabio Estevam" , "NXP Linux Team" , "Ahmad Fatoum" , "sigma star Kernel Team" , "David Howells" , "Li Yang" , "Paul Moore" , "James Morris" , "Serge E. Hallyn" , "Paul E. McKenney" , "Randy Dunlap" , "Catalin Marinas" , "Rafael J. Wysocki" , "Tejun Heo" , "Steven Rostedt (Google)" , , , , , , , , , "Richard Weinberger" , "David Oberhollenzer" Subject: Re: [PATCH v3 1/3] crypto: mxs-dcp: Add support for hardware provided keys From: "Jarkko Sakkinen" To: "David Gstir" , "Mimi Zohar" , "James Bottomley" , "Herbert Xu" , "David S. Miller" X-Mailer: aerc 0.14.0 References: <20230918141826.8139-1-david@sigma-star.at> <20230918141826.8139-2-david@sigma-star.at> In-Reply-To: <20230918141826.8139-2-david@sigma-star.at> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230925_082235_467677_CBC9FF7C X-CRM114-Status: GOOD ( 17.01 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Mon Sep 18, 2023 at 5:18 PM EEST, David Gstir wrote: > DCP is capable to performing AES with hardware-bound keys. > These keys are not stored in main memory and are therefore not directly > accessible by the operating system. > > So instead of feeding the key into DCP, we need to place a > reference to such a key before initiating the crypto operation. > Keys are referenced by a one byte identifiers. Not sure what the action of feeding key into DCP even means if such action does not exists. What you probably would want to describe here is how keys get created and how they are referenced by the kernel. For the "use" part please try to avoid academic paper style long expression starting with "we" pronomine. So the above paragraph would normalize into "The keys inside DCP are referenced by one byte identifier". Here of course would be for the context nice to know what is this set of DCP keys. E.g. are total 256 keys or some subset? When using too much prose there can be surprsingly little digestable information, thus this nitpicking. > DCP supports 6 different keys: 4 slots in the secure memory area, > a one time programmable key which can be burnt via on-chip fuses > and an unique device key. > > Using these keys is restricted to in-kernel users that use them as building > block for other crypto tools such as trusted keys. Allowing userspace > (e.g. via AF_ALG) to use these keys to crypt or decrypt data is a security > risk, because there is no access control mechanism. Unless this patch has anything else than trusted keys this should not be an open-ended sentence. You want to say roughly that DCP hardware keys are implemented for the sake to implement trusted keys support, and exactly and only that. This description also lacks actions taken by the code changes below, which is really the beef of any commit description. BR, Jarkko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel