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=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 DF231C43600 for ; Thu, 1 Apr 2021 10:56:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B60B0610E6 for ; Thu, 1 Apr 2021 10:56:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233970AbhDAKz3 convert rfc822-to-8bit (ORCPT ); Thu, 1 Apr 2021 06:55:29 -0400 Received: from lithops.sigma-star.at ([195.201.40.130]:60844 "EHLO lithops.sigma-star.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234057AbhDAKy5 (ORCPT ); Thu, 1 Apr 2021 06:54:57 -0400 Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id E55D960FB28C; Thu, 1 Apr 2021 12:53:38 +0200 (CEST) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id kHf6bXNSWmLt; Thu, 1 Apr 2021 12:53:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id 76B666071A7C; Thu, 1 Apr 2021 12:53:38 +0200 (CEST) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Q_FICC5ApzVQ; Thu, 1 Apr 2021 12:53:38 +0200 (CEST) Received: from lithops.sigma-star.at (lithops.sigma-star.at [195.201.40.130]) by lithops.sigma-star.at (Postfix) with ESMTP id 3928660FB28C; Thu, 1 Apr 2021 12:53:38 +0200 (CEST) Date: Thu, 1 Apr 2021 12:53:38 +0200 (CEST) From: Richard Weinberger To: Ahmad Fatoum Cc: Jarkko Sakkinen , horia geanta , Mimi Zohar , aymen sghaier , Herbert Xu , davem , James Bottomley , kernel , David Howells , James Morris , "Serge E. Hallyn" , Steffen Trumtrar , Udit Agarwal , Jan Luebbe , david , Franck Lenormand , Sumit Garg , linux-integrity , "open list, ASYMMETRIC KEYS" , Linux Crypto Mailing List , linux-kernel , LSM Message-ID: <717795270.139671.1617274418087.JavaMail.zimbra@nod.at> In-Reply-To: <27d7d3fa-5df8-1880-df21-200de31cc629@pengutronix.de> References: <897df7dd-83a1-3e3e-1d9f-5a1adfd5b2fb@pengutronix.de> <1263763932.139584.1617272457698.JavaMail.zimbra@nod.at> <27d7d3fa-5df8-1880-df21-200de31cc629@pengutronix.de> Subject: Re: [PATCH v1 0/3] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Originating-IP: [195.201.40.130] X-Mailer: Zimbra 8.8.12_GA_3807 (ZimbraWebClient - FF78 (Linux)/8.8.12_GA_3809) Thread-Topic: KEYS: trusted: Introduce support for NXP CAAM-based trusted keys Thread-Index: DfD/q4ZvfJZf2mMkmIDHHYWuBGwS1g== Precedence: bulk List-ID: Ahmad, ----- Ursprüngliche Mail ----- > Do you mean systemd-cryptsetup? It looks to me like it's just a way to supply > the keyphrase. With trusted keys and a keyphrase unknown to userspace, this > won't work. Nah, I meant existing scripts/service Files. > I don't (yet) see the utility of it without LUKS. Perhaps a command dump on how > to do the same I did with dmsetup, but with cryptsetup plain instead could > help me to see the benefits? My reasoning is simple, why do I need a different tool when there is already one that could do the task too? Usually the systems I get my hands on use already dm-crypt with cryptsetup in some way. So I have the tooling already in my initramfs, etc.. and need to adopt the callers of cryptsetup a little. If I need all of a sudden different/additional tooling, it means more work, more docs to write, more hassle with crypto/system reviewers, etc... I don't want you to force to use cryptsetup. The only goal was pointing out that it can be done with cryptsetup and that there is already code such that no work is done twice. One the kernel side it does not matter. Thanks, //richard