Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp3523028pxv; Mon, 19 Jul 2021 02:14:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyDwkPOFznfBqAVFVAnG0NBwDD66wlyRT3bPrSanLg5PfhzvKRvAL/rAy7WhTI5sZuw32v+ X-Received: by 2002:a05:6602:2245:: with SMTP id o5mr18572911ioo.20.1626686071960; Mon, 19 Jul 2021 02:14:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626686071; cv=none; d=google.com; s=arc-20160816; b=BdvxmPBVfe1H3RuDiRypRf+rq5DJvj2lvlq9Iw+yb7DaG6p8E0gzLhcWR23Hl5/oPX 8b7DQVL21ciftMsqRzib6X+v+beuNC+O9ueQLB3BpIz+gTQoTZAndRhEJtmuA5z9hpkl 5YvlhWv/tkk99UtI4WJGMaN3lbJgqAfomskAcJjOt8VR1UhYwu0a4XIzzJ4Ya2EE2N2p Ma0PzpTmTnqU3W+SGy5G8pGTQ/VOEJktZhK1ao9XEGCIuNoULkF9DueByM7zWjTWc/2l CKmbLwEAk7bOQ9Za0i13SuSuNPoONzmdlC4cJXBlSUwzjMIquyLOVo01fCUtVnD8MTOv rXMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=GeYs5mUjYDt0F2pt9uFHOrxKHtsEsE7bcDIp+B4aHvo=; b=Qjq3WX0qAcClYqc85xnaXLb/9MdgKn0jJ67ktjJtsg60LV5hpwKhx9AnD5ipLzbc3A ip3emuIA1kAT+gKnFBimeRGoOwEcHT+0iiUhQJsSXupnJzQ/DiX5q5tHioddH2037EM8 I2WNTMreQwUQCpwmZZj6FlrDSwSObIDZdwIcI+ju7PvaoYhdS2Pt3N2Ybl87CrRRGW8y qpnXSFDK6Tor9Ty7SIvdB8dOA/ArUdiZcBOQLYMuCVNYAK1tHZIxLVnCki3gyxnWUmat CjQdr9Uiz6PvGVHTDaSsfaJlrbPkkYQN2I78h1F4DlVn1BQXGsFNYuMBof7MAXd1UJCQ wvWw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rammhold-de.20150623.gappssmtp.com header.s=20150623 header.b=bhk6S9NO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x4si19194067ilh.33.2021.07.19.02.14.20; Mon, 19 Jul 2021 02:14:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@rammhold-de.20150623.gappssmtp.com header.s=20150623 header.b=bhk6S9NO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235150AbhGSIc7 (ORCPT + 99 others); Mon, 19 Jul 2021 04:32:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59264 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235518AbhGSIc6 (ORCPT ); Mon, 19 Jul 2021 04:32:58 -0400 Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2B600C061762 for ; Mon, 19 Jul 2021 01:14:42 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id t5so21070735wrw.12 for ; Mon, 19 Jul 2021 02:13:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rammhold-de.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=GeYs5mUjYDt0F2pt9uFHOrxKHtsEsE7bcDIp+B4aHvo=; b=bhk6S9NOUkSPKEjpHWFtoWIrtMtNdrMDrY5331MwknZwHcBc/vMseahQRkTCnlR9A2 6EKlOTD94+BUjmtwWwufy845nmzbvkGyuoJ6R5OL7MizcQXw4FwX282tzMZBmYl1+zU6 jBfoOBB4/QBA7a2XetktBSzCym1/4KiHpdkG6+gbCCnQ3GeJ8+3rWey5LWuhUZQdZLp0 tZ5NamtSPFmX+ROipJX5O2h5Nq5iZEAEUtC+OyeEvwRnVqtd1Mz0HrAhJ88f54T4x8X8 R0ostqChH3EE4MFoUylTYQUf00mCBjbG+mmlsas0blGJu2KCLyHiTHlHGa/a6HbY/jh4 RwVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=GeYs5mUjYDt0F2pt9uFHOrxKHtsEsE7bcDIp+B4aHvo=; b=opJJcOXUNOyceHen2QAuHRLpAi3lFkKRDhA2q31vqe8rnpMo1nMLvReIvJmyRdFDOR ZCiBxKkauilvj/3vhUAghbcUU/1XHQ4vqJ/Nu5/JTVVdM1RH14qEi49Zcmj0jHzApTvJ qE1jweLeZokZo24PtlljnaVLLMl++/NV7bOQyTP9/2TYv/qtnKG5ASMF27VNuYNG08rN 9jQygEG4mNwpxP1PawuylrlGf8eBMSBhFHtoWSP2stLX1+D/XtoXYh/ScRAWgKc9we3x FTNofvV2ZD/hdEh43AXX1xJ1uzH11fRbpln3wxmOKSEieFbBDrIkaRQ3NgXm6qJtdgTV 1kPQ== X-Gm-Message-State: AOAM530Ty9oTuAzC1bzHkAilYamHwpDDAj9Y9C/ezcFXpkJ0K4FR80hh /gPqlFh8gUkMKgl1uD1M4w13cQ== X-Received: by 2002:a5d:464b:: with SMTP id j11mr28745704wrs.356.1626686016925; Mon, 19 Jul 2021 02:13:36 -0700 (PDT) Received: from localhost ([2a00:e67:1fd:a:4af1:ba6e:49d3:2e89]) by smtp.gmail.com with ESMTPSA id r18sm19820621wrt.96.2021.07.19.02.13.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Jul 2021 02:13:36 -0700 (PDT) Date: Mon, 19 Jul 2021 11:13:35 +0200 From: andreas@rammhold.de To: Sumit Garg , Ahmad Fatoum Cc: James Bottomley , Jarkko Sakkinen , Mimi Zohar , David Howells , James Morris , "Serge E . Hallyn" , linux-integrity , "open list:ASYMMETRIC KEYS" , "open list:SECURITY SUBSYSTEM" , Linux Kernel Mailing List , Pengutronix Kernel Team Subject: Re: [PATCH] KEYS: trusted: Fix trusted key backends when building as module Message-ID: <20210719091335.vwfebcpkf4pag3wm@wrt> References: <20210716081722.4130161-1-andreas@rammhold.de> <0a684d56-66d0-184e-4853-9faafa2d243d@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13:36 19.07.21, Sumit Garg wrote: > On Mon, 19 Jul 2021 at 12:40, Ahmad Fatoum wrote: > > > > Hello Andreas, > > > > On 16.07.21 10:17, Andreas Rammhold wrote: > > > Before this commit the kernel could end up with no trusted key sources > > > even thought both of the currently supported backends (tpm & tee) were > > > compoiled as modules. This manifested in the trusted key type not being > > > registered at all. > > > > I assume (TPM) trusted key module use worked before the TEE rework? If so, > > > > an appropriate Fixes: Tag would then be in order. > > > > > When checking if a CONFIG_… preprocessor variable is defined we only > > > test for the builtin (=y) case and not the module (=m) case. By using > > > the IS_ENABLE(…) macro we to test for both cases. > > > > It looks to me like you could now provoke a link error if TEE is a module > > and built-in trusted key core tries to link against trusted_key_tee_ops. > > > > That's true. > > > One solution for that IS_REACHABLE(). Another is to address the root cause, > > which is the inflexible trusted keys Kconfig description: > > > > - Trusted keys despite TEE support can still only be built when TCG_TPM is enabled > > - There is no support to have TEE or TPM enabled without using those for > > enabled trusted keys as well > > - As you noticed, module build of the backend has issues > > > > I addressed these three issues in a patch[1], a month ago, but have yet to > > receive feedback. > > That's an oversight on my part since this patch was part of the new > CAAM trust source patch-set. Although I do admit that it was on my > TODO list. So I have provided some feedback on that patch. Can you > post the next version as an independent fix patch? Thank you both for the feedback. In light of thes feedback and the patchset that Ahmad posted I'll not address the issue and not send a v2 of this. I'll try to squeeze in some time to test the other patch and provide feedback. Andi