Message ID | 20231006051801.423973-1-sumit.garg@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:a888:0:b0:403:3b70:6f57 with SMTP id x8csp98781vqo; Thu, 5 Oct 2023 22:18:29 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGP/YuIchnc5AvJchDtaDVujxClPvc4JYCDG1JCzrJfVkU9QvAj2Lqq3KH/r4Z9EikJRUWf X-Received: by 2002:a05:6a00:1687:b0:68a:5395:7aa5 with SMTP id k7-20020a056a00168700b0068a53957aa5mr7623176pfc.17.1696569508861; Thu, 05 Oct 2023 22:18:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696569508; cv=none; d=google.com; s=arc-20160816; b=Goi7JzxwBHp1mUKzK7fNViu+JsAybmwQ7JZWscVrxnBbiBQTvi4IrLzud8y9AnbPiS U2h5+SAMt8ckTRzNlelXd3ZydiAOuMsR+/oUMUdZPg7aA18RkTdup+2sraCRyTSMlpMD SatlQUbtMd4fuCN+OKPJOyc825OR+84VPp9kcBA4natGX7EzoLF5e5XFfSiX41pQBmJk c/SBiPtq873Fz8ZvjECWLJ3bO/6fW9I1XLNmBMr0D5mmhvpfgzn8BMIbWcZDv4j40ybe kAUn6nw0zw9kxg1HnH4g6wDyjUfz9yxl7t3Ct9uN+4+dnyc+fY4SK3wMk2l9snc+hMkd Orjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=XUmzwFWm2fPwy4CB12OZE+k96a2phqo45N6Zs8xEb94=; fh=su2vn+2ye5a4musRcPPzouLI5i8pJEf7GqfZKbS4+MA=; b=IIGBwOmo5NZt1CQiBVCQQkHAMLGudo2CPIILB0ZkgutDZV7/2mLvfSqAV36C5vcDNR /56rzpd7hJr4jELnd9tgQe7BiOfvPpl8yllrqTjCPGY4aL8GKdzdl2AVe6yHSpDYEIne atZutwscJBAD99C7dI68aFAf8szfhSipw8psvuS3avg9kJ23wzZUwV37F6dG2xhid3zg kuGHL7Uj1GCr6MejmNGS2ecx4ASCyVyOTkRQvedis+LMNQ08ckHwrNq8i40dpmy3Xs58 dfcunLgMvhbhbuunJcS3SfKfbIc7mDL3a7Qya1kBddMy1EF+LX7WSr2cHkGYJvDJi4bc DFgA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=aazrwwBs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id h15-20020a65638f000000b005778df5647dsi2839909pgv.401.2023.10.05.22.18.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Oct 2023 22:18:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=aazrwwBs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 8684383AC0FC; Thu, 5 Oct 2023 22:18:27 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230126AbjJFFSX (ORCPT <rfc822;ezelljr.billy@gmail.com> + 18 others); Fri, 6 Oct 2023 01:18:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46736 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229876AbjJFFSV (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 6 Oct 2023 01:18:21 -0400 Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3208ECA for <linux-kernel@vger.kernel.org>; Thu, 5 Oct 2023 22:18:20 -0700 (PDT) Received: by mail-oi1-x22c.google.com with SMTP id 5614622812f47-3ae5ce4a4ceso1188622b6e.1 for <linux-kernel@vger.kernel.org>; Thu, 05 Oct 2023 22:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1696569499; x=1697174299; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=XUmzwFWm2fPwy4CB12OZE+k96a2phqo45N6Zs8xEb94=; b=aazrwwBsCaVyDnt4g/1TjY2zt3RrEiu45pqCtbzhpZzjaoPvrL6KDxILE2efffc0ZM 6TuY8QchUSUG6JEypfMG62ASzbQLQQzAzgeJud7h3p/xQ2XCxx9XqfYjcdl/DO88wD9M KxAwB5wY8DMQJO72lUzV5sStH+7Pn32BiPqFqL5STu3H9RhqZWWYVbygTTcZO/fKfpLD pd+4MSUEIoAXzGR2sOk4cExDhO2WEI6KrK2RRrjley6FEWiY+wnmv9yPfPTf9ZWzxu19 6nWijgppG9nVBpWzCB0BN4zy/lGr0NIBA5DliqXAnsu+/1x/u1Kkr26cusSQkzX6oxZM fGXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696569499; x=1697174299; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XUmzwFWm2fPwy4CB12OZE+k96a2phqo45N6Zs8xEb94=; b=D5kxwc6tp8mu2AK+gu8Ysv0T4qQ+iOJr4495twveYwp1yEQs1P5pRWiwvVSRb6XQuy XUnM9WnRgtyovXRmolmprVL0aQKI8Xlc+WWcrvT2UOxdQi6xDS0xc4RqrUlg1m2RlrWA SAl/HVHrBW2P2TdfrjpnvAzAuX1DMnhvtUL02mEcJMrcvOLY/tPkmBQ8NhnFxVMeCzdc oRx1Wbc8DX+BJaDW2Vrb/Psq6lVN0GXcgLxawXN2+XlAyJdbw52vyU7HkoahSb3mKqNA mId2v/y5vXsmxkHKMzLhs9stnAMo081MbDzr9IW8yZuVD9NlT3wtkBHNxfVFCKybFTWQ 7MRw== X-Gm-Message-State: AOJu0YycgJplgqWp3wSVElT0SG+JmT1c27LOw4gaAQ3phGsuq8YnzAyJ cbFweSZbfFl0BQCBldRhAxbD+w== X-Received: by 2002:a05:6808:144d:b0:3ad:c5f3:36c6 with SMTP id x13-20020a056808144d00b003adc5f336c6mr8475294oiv.38.1696569499432; Thu, 05 Oct 2023 22:18:19 -0700 (PDT) Received: from sumit-X1.. ([223.178.210.23]) by smtp.gmail.com with ESMTPSA id w25-20020a639359000000b00553dcfc2179sm2393874pgm.52.2023.10.05.22.18.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Oct 2023 22:18:19 -0700 (PDT) From: Sumit Garg <sumit.garg@linaro.org> To: torvalds@linux-foundation.org, jarkko@kernel.org, peterz@infradead.org, zohar@linux.ibm.com Cc: linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org, jejb@linux.ibm.com, David.Kaplan@amd.com, bp@alien8.de, mingo@kernel.org, x86@kernel.org, regressions@leemhuis.info, Sumit Garg <sumit.garg@linaro.org>, Hyeonggon Yoo <42.hyeyoo@gmail.com> Subject: [PATCH v2] KEYS: trusted: Remove redundant static calls usage Date: Fri, 6 Oct 2023 10:48:01 +0530 Message-Id: <20231006051801.423973-1-sumit.garg@linaro.org> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Thu, 05 Oct 2023 22:18:27 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778982069299596704 X-GMAIL-MSGID: 1778982069299596704 |
Series |
[v2] KEYS: trusted: Remove redundant static calls usage
|
|
Commit Message
Sumit Garg
Oct. 6, 2023, 5:18 a.m. UTC
Static calls invocations aren't well supported from module __init and
__exit functions. Especially the static call from cleanup_trusted() led
to a crash on x86 kernel with CONFIG_DEBUG_VIRTUAL=y.
However, the usage of static call invocations for trusted_key_init()
and trusted_key_exit() don't add any value from either a performance or
security perspective. Hence switch to use indirect function calls instead.
Note here that although it will fix the current crash report, ultimately
the static call infrastructure should be fixed to either support its
future usage from module __init and __exit functions or not.
Reported-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>
Link: https://lore.kernel.org/lkml/ZRhKq6e5nF%2F4ZIV1@fedora/#t
Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework")
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
Changes in v2:
- Polish commit message as per comments from Mimi
security/keys/trusted-keys/trusted_core.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
Comments
On Fri, Oct 6, 2023 at 2:18 PM Sumit Garg <sumit.garg@linaro.org> wrote: > > Static calls invocations aren't well supported from module __init and > __exit functions. Especially the static call from cleanup_trusted() led > to a crash on x86 kernel with CONFIG_DEBUG_VIRTUAL=y. > > However, the usage of static call invocations for trusted_key_init() > and trusted_key_exit() don't add any value from either a performance or > security perspective. Hence switch to use indirect function calls instead. > > Note here that although it will fix the current crash report, ultimately > the static call infrastructure should be fixed to either support its > future usage from module __init and __exit functions or not. > > Reported-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> > Link: https://lore.kernel.org/lkml/ZRhKq6e5nF%2F4ZIV1@fedora/#t > Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework") > Signed-off-by: Sumit Garg <sumit.garg@linaro.org> I verified that this patch fixes the original problem. Thanks! Feel free to add: Tested-By: Hyeonggon Yoo <42.hyeyoo@gmail.com> Hyeonggon > --- > > Changes in v2: > - Polish commit message as per comments from Mimi > > security/keys/trusted-keys/trusted_core.c | 13 +++++-------- > 1 file changed, 5 insertions(+), 8 deletions(-) > > diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c > index c6fc50d67214..85fb5c22529a 100644 > --- a/security/keys/trusted-keys/trusted_core.c > +++ b/security/keys/trusted-keys/trusted_core.c > @@ -44,13 +44,12 @@ static const struct trusted_key_source trusted_key_sources[] = { > #endif > }; > > -DEFINE_STATIC_CALL_NULL(trusted_key_init, *trusted_key_sources[0].ops->init); > DEFINE_STATIC_CALL_NULL(trusted_key_seal, *trusted_key_sources[0].ops->seal); > DEFINE_STATIC_CALL_NULL(trusted_key_unseal, > *trusted_key_sources[0].ops->unseal); > DEFINE_STATIC_CALL_NULL(trusted_key_get_random, > *trusted_key_sources[0].ops->get_random); > -DEFINE_STATIC_CALL_NULL(trusted_key_exit, *trusted_key_sources[0].ops->exit); > +static void (*trusted_key_exit)(void); > static unsigned char migratable; > > enum { > @@ -359,19 +358,16 @@ static int __init init_trusted(void) > if (!get_random) > get_random = kernel_get_random; > > - static_call_update(trusted_key_init, > - trusted_key_sources[i].ops->init); > static_call_update(trusted_key_seal, > trusted_key_sources[i].ops->seal); > static_call_update(trusted_key_unseal, > trusted_key_sources[i].ops->unseal); > static_call_update(trusted_key_get_random, > get_random); > - static_call_update(trusted_key_exit, > - trusted_key_sources[i].ops->exit); > + trusted_key_exit = trusted_key_sources[i].ops->exit; > migratable = trusted_key_sources[i].ops->migratable; > > - ret = static_call(trusted_key_init)(); > + ret = trusted_key_sources[i].ops->init(); > if (!ret) > break; > } > @@ -388,7 +384,8 @@ static int __init init_trusted(void) > > static void __exit cleanup_trusted(void) > { > - static_call_cond(trusted_key_exit)(); > + if (trusted_key_exit) > + (*trusted_key_exit)(); > } > > late_initcall(init_trusted); > -- > 2.34.1 >
On Fri, 2023-10-06 at 10:48 +0530, Sumit Garg wrote: > Static calls invocations aren't well supported from module __init and > __exit functions. Especially the static call from cleanup_trusted() led > to a crash on x86 kernel with CONFIG_DEBUG_VIRTUAL=y. > > However, the usage of static call invocations for trusted_key_init() > and trusted_key_exit() don't add any value from either a performance or > security perspective. Hence switch to use indirect function calls instead. > > Note here that although it will fix the current crash report, ultimately > the static call infrastructure should be fixed to either support its > future usage from module __init and __exit functions or not. > > Reported-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> > Link: https://lore.kernel.org/lkml/ZRhKq6e5nF%2F4ZIV1@fedora/#t > Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework") > Signed-off-by: Sumit Garg <sumit.garg@linaro.org> > --- > > Changes in v2: > - Polish commit message as per comments from Mimi > > security/keys/trusted-keys/trusted_core.c | 13 +++++-------- > 1 file changed, 5 insertions(+), 8 deletions(-) > > diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c > index c6fc50d67214..85fb5c22529a 100644 > --- a/security/keys/trusted-keys/trusted_core.c > +++ b/security/keys/trusted-keys/trusted_core.c > @@ -44,13 +44,12 @@ static const struct trusted_key_source trusted_key_sources[] = { > #endif > }; > > -DEFINE_STATIC_CALL_NULL(trusted_key_init, *trusted_key_sources[0].ops->init); > DEFINE_STATIC_CALL_NULL(trusted_key_seal, *trusted_key_sources[0].ops->seal); > DEFINE_STATIC_CALL_NULL(trusted_key_unseal, > *trusted_key_sources[0].ops->unseal); > DEFINE_STATIC_CALL_NULL(trusted_key_get_random, > *trusted_key_sources[0].ops->get_random); > -DEFINE_STATIC_CALL_NULL(trusted_key_exit, *trusted_key_sources[0].ops->exit); > +static void (*trusted_key_exit)(void); > static unsigned char migratable; > > enum { > @@ -359,19 +358,16 @@ static int __init init_trusted(void) > if (!get_random) > get_random = kernel_get_random; > > - static_call_update(trusted_key_init, > - trusted_key_sources[i].ops->init); > static_call_update(trusted_key_seal, > trusted_key_sources[i].ops->seal); > static_call_update(trusted_key_unseal, > trusted_key_sources[i].ops->unseal); > static_call_update(trusted_key_get_random, > get_random); > - static_call_update(trusted_key_exit, > - trusted_key_sources[i].ops->exit); > + trusted_key_exit = trusted_key_sources[i].ops->exit; > migratable = trusted_key_sources[i].ops->migratable; > > - ret = static_call(trusted_key_init)(); > + ret = trusted_key_sources[i].ops->init(); > if (!ret) > break; > } > @@ -388,7 +384,8 @@ static int __init init_trusted(void) > > static void __exit cleanup_trusted(void) > { > - static_call_cond(trusted_key_exit)(); > + if (trusted_key_exit) > + (*trusted_key_exit)(); > } > > late_initcall(init_trusted); Would it be less confusing to require trusted_key_exit from each? BR, Jarkko
On Tue, 10 Oct 2023 at 18:03, Jarkko Sakkinen <jarkko@kernel.org> wrote: > > On Fri, 2023-10-06 at 10:48 +0530, Sumit Garg wrote: > > Static calls invocations aren't well supported from module __init and > > __exit functions. Especially the static call from cleanup_trusted() led > > to a crash on x86 kernel with CONFIG_DEBUG_VIRTUAL=y. > > > > However, the usage of static call invocations for trusted_key_init() > > and trusted_key_exit() don't add any value from either a performance or > > security perspective. Hence switch to use indirect function calls instead. > > > > Note here that although it will fix the current crash report, ultimately > > the static call infrastructure should be fixed to either support its > > future usage from module __init and __exit functions or not. > > > > Reported-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> > > Link: https://lore.kernel.org/lkml/ZRhKq6e5nF%2F4ZIV1@fedora/#t > > Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework") > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org> > > --- > > > > Changes in v2: > > - Polish commit message as per comments from Mimi > > > > security/keys/trusted-keys/trusted_core.c | 13 +++++-------- > > 1 file changed, 5 insertions(+), 8 deletions(-) > > > > diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c > > index c6fc50d67214..85fb5c22529a 100644 > > --- a/security/keys/trusted-keys/trusted_core.c > > +++ b/security/keys/trusted-keys/trusted_core.c > > @@ -44,13 +44,12 @@ static const struct trusted_key_source trusted_key_sources[] = { > > #endif > > }; > > > > -DEFINE_STATIC_CALL_NULL(trusted_key_init, *trusted_key_sources[0].ops->init); > > DEFINE_STATIC_CALL_NULL(trusted_key_seal, *trusted_key_sources[0].ops->seal); > > DEFINE_STATIC_CALL_NULL(trusted_key_unseal, > > *trusted_key_sources[0].ops->unseal); > > DEFINE_STATIC_CALL_NULL(trusted_key_get_random, > > *trusted_key_sources[0].ops->get_random); > > -DEFINE_STATIC_CALL_NULL(trusted_key_exit, *trusted_key_sources[0].ops->exit); > > +static void (*trusted_key_exit)(void); > > static unsigned char migratable; > > > > enum { > > @@ -359,19 +358,16 @@ static int __init init_trusted(void) > > if (!get_random) > > get_random = kernel_get_random; > > > > - static_call_update(trusted_key_init, > > - trusted_key_sources[i].ops->init); > > static_call_update(trusted_key_seal, > > trusted_key_sources[i].ops->seal); > > static_call_update(trusted_key_unseal, > > trusted_key_sources[i].ops->unseal); > > static_call_update(trusted_key_get_random, > > get_random); > > - static_call_update(trusted_key_exit, > > - trusted_key_sources[i].ops->exit); > > + trusted_key_exit = trusted_key_sources[i].ops->exit; > > migratable = trusted_key_sources[i].ops->migratable; > > > > - ret = static_call(trusted_key_init)(); > > + ret = trusted_key_sources[i].ops->init(); > > if (!ret) > > break; > > } > > @@ -388,7 +384,8 @@ static int __init init_trusted(void) > > > > static void __exit cleanup_trusted(void) > > { > > - static_call_cond(trusted_key_exit)(); > > + if (trusted_key_exit) > > + (*trusted_key_exit)(); > > } > > > > late_initcall(init_trusted); > > Would it be less confusing to require trusted_key_exit from each? > It is already required for each trust source to provide exit callback but this NULL check was added via this fix [1] in case there isn't any trust source present. [1] https://lkml.kernel.org/stable/20220126184155.220814-1-dave.kleikamp@oracle.com/ -Sumit > BR, Jarkko >
On Tue, 2023-10-10 at 18:44 +0530, Sumit Garg wrote: > On Tue, 10 Oct 2023 at 18:03, Jarkko Sakkinen <jarkko@kernel.org> wrote: > > > > On Fri, 2023-10-06 at 10:48 +0530, Sumit Garg wrote: > > > Static calls invocations aren't well supported from module __init and > > > __exit functions. Especially the static call from cleanup_trusted() led > > > to a crash on x86 kernel with CONFIG_DEBUG_VIRTUAL=y. > > > > > > However, the usage of static call invocations for trusted_key_init() > > > and trusted_key_exit() don't add any value from either a performance or > > > security perspective. Hence switch to use indirect function calls instead. > > > > > > Note here that although it will fix the current crash report, ultimately > > > the static call infrastructure should be fixed to either support its > > > future usage from module __init and __exit functions or not. > > > > > > Reported-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> > > > Link: https://lore.kernel.org/lkml/ZRhKq6e5nF%2F4ZIV1@fedora/#t > > > Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework") > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org> > > > --- > > > > > > Changes in v2: > > > - Polish commit message as per comments from Mimi > > > > > > security/keys/trusted-keys/trusted_core.c | 13 +++++-------- > > > 1 file changed, 5 insertions(+), 8 deletions(-) > > > > > > diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c > > > index c6fc50d67214..85fb5c22529a 100644 > > > --- a/security/keys/trusted-keys/trusted_core.c > > > +++ b/security/keys/trusted-keys/trusted_core.c > > > @@ -44,13 +44,12 @@ static const struct trusted_key_source trusted_key_sources[] = { > > > #endif > > > }; > > > > > > -DEFINE_STATIC_CALL_NULL(trusted_key_init, *trusted_key_sources[0].ops->init); > > > DEFINE_STATIC_CALL_NULL(trusted_key_seal, *trusted_key_sources[0].ops->seal); > > > DEFINE_STATIC_CALL_NULL(trusted_key_unseal, > > > *trusted_key_sources[0].ops->unseal); > > > DEFINE_STATIC_CALL_NULL(trusted_key_get_random, > > > *trusted_key_sources[0].ops->get_random); > > > -DEFINE_STATIC_CALL_NULL(trusted_key_exit, *trusted_key_sources[0].ops->exit); > > > +static void (*trusted_key_exit)(void); > > > static unsigned char migratable; > > > > > > enum { > > > @@ -359,19 +358,16 @@ static int __init init_trusted(void) > > > if (!get_random) > > > get_random = kernel_get_random; > > > > > > - static_call_update(trusted_key_init, > > > - trusted_key_sources[i].ops->init); > > > static_call_update(trusted_key_seal, > > > trusted_key_sources[i].ops->seal); > > > static_call_update(trusted_key_unseal, > > > trusted_key_sources[i].ops->unseal); > > > static_call_update(trusted_key_get_random, > > > get_random); > > > - static_call_update(trusted_key_exit, > > > - trusted_key_sources[i].ops->exit); > > > + trusted_key_exit = trusted_key_sources[i].ops->exit; > > > migratable = trusted_key_sources[i].ops->migratable; > > > > > > - ret = static_call(trusted_key_init)(); > > > + ret = trusted_key_sources[i].ops->init(); > > > if (!ret) > > > break; > > > } > > > @@ -388,7 +384,8 @@ static int __init init_trusted(void) > > > > > > static void __exit cleanup_trusted(void) > > > { > > > - static_call_cond(trusted_key_exit)(); > > > + if (trusted_key_exit) > > > + (*trusted_key_exit)(); > > > } > > > > > > late_initcall(init_trusted); > > > > Would it be less confusing to require trusted_key_exit from each? > > > > It is already required for each trust source to provide exit callback > but this NULL check was added via this fix [1] in case there isn't any > trust source present. > > [1] https://lkml.kernel.org/stable/20220126184155.220814-1-dave.kleikamp@oracle.com/ I'd considering creating a placeholder trusted_key_default_exit() with perhaps pr_debug() statement acknowledging it getting called. Hmm.. if we had that I wonder if we could get away with __weak... Then you would not need to assign anything. This is not through-out analyzed. Tbh I'm not sure how module loader handles this type of scenario but at least the placeholder function would make sense in any case. If abusing weak symbols was in-fact possible probably then the whole idea of using static_call could be thrown to garbage bin but there's now a lot of context here related on how module loader works linux that I'm ignoring... BR, Jarkko
Hello Jarkko, On 10.10.23 15:49, Jarkko Sakkinen wrote: > On Tue, 2023-10-10 at 18:44 +0530, Sumit Garg wrote: >> On Tue, 10 Oct 2023 at 18:03, Jarkko Sakkinen <jarkko@kernel.org> wrote: >>> >>> On Fri, 2023-10-06 at 10:48 +0530, Sumit Garg wrote: >>>> Static calls invocations aren't well supported from module __init and >>>> __exit functions. Especially the static call from cleanup_trusted() led >>>> to a crash on x86 kernel with CONFIG_DEBUG_VIRTUAL=y. >>>> >>>> However, the usage of static call invocations for trusted_key_init() >>>> and trusted_key_exit() don't add any value from either a performance or >>>> security perspective. Hence switch to use indirect function calls instead. >>>> >>>> Note here that although it will fix the current crash report, ultimately >>>> the static call infrastructure should be fixed to either support its >>>> future usage from module __init and __exit functions or not. >>>> >>>> Reported-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> >>>> Link: https://lore.kernel.org/lkml/ZRhKq6e5nF%2F4ZIV1@fedora/#t >>>> Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework") >>>> Signed-off-by: Sumit Garg <sumit.garg@linaro.org> >>>> --- >>>> >>>> Changes in v2: >>>> - Polish commit message as per comments from Mimi >>>> >>>> security/keys/trusted-keys/trusted_core.c | 13 +++++-------- >>>> 1 file changed, 5 insertions(+), 8 deletions(-) >>>> >>>> diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c >>>> index c6fc50d67214..85fb5c22529a 100644 >>>> --- a/security/keys/trusted-keys/trusted_core.c >>>> +++ b/security/keys/trusted-keys/trusted_core.c >>>> @@ -44,13 +44,12 @@ static const struct trusted_key_source trusted_key_sources[] = { >>>> #endif >>>> }; >>>> >>>> -DEFINE_STATIC_CALL_NULL(trusted_key_init, *trusted_key_sources[0].ops->init); >>>> DEFINE_STATIC_CALL_NULL(trusted_key_seal, *trusted_key_sources[0].ops->seal); >>>> DEFINE_STATIC_CALL_NULL(trusted_key_unseal, >>>> *trusted_key_sources[0].ops->unseal); >>>> DEFINE_STATIC_CALL_NULL(trusted_key_get_random, >>>> *trusted_key_sources[0].ops->get_random); >>>> -DEFINE_STATIC_CALL_NULL(trusted_key_exit, *trusted_key_sources[0].ops->exit); >>>> +static void (*trusted_key_exit)(void); >>>> static unsigned char migratable; >>>> >>>> enum { >>>> @@ -359,19 +358,16 @@ static int __init init_trusted(void) >>>> if (!get_random) >>>> get_random = kernel_get_random; >>>> >>>> - static_call_update(trusted_key_init, >>>> - trusted_key_sources[i].ops->init); >>>> static_call_update(trusted_key_seal, >>>> trusted_key_sources[i].ops->seal); >>>> static_call_update(trusted_key_unseal, >>>> trusted_key_sources[i].ops->unseal); >>>> static_call_update(trusted_key_get_random, >>>> get_random); >>>> - static_call_update(trusted_key_exit, >>>> - trusted_key_sources[i].ops->exit); >>>> + trusted_key_exit = trusted_key_sources[i].ops->exit; >>>> migratable = trusted_key_sources[i].ops->migratable; >>>> >>>> - ret = static_call(trusted_key_init)(); >>>> + ret = trusted_key_sources[i].ops->init(); >>>> if (!ret) >>>> break; >>>> } >>>> @@ -388,7 +384,8 @@ static int __init init_trusted(void) >>>> >>>> static void __exit cleanup_trusted(void) >>>> { >>>> - static_call_cond(trusted_key_exit)(); >>>> + if (trusted_key_exit) >>>> + (*trusted_key_exit)(); >>>> } >>>> >>>> late_initcall(init_trusted); >>> >>> Would it be less confusing to require trusted_key_exit from each? >>> >> >> It is already required for each trust source to provide exit callback >> but this NULL check was added via this fix [1] in case there isn't any >> trust source present. >> >> [1] https://lkml.kernel.org/stable/20220126184155.220814-1-dave.kleikamp@oracle.com/ > > I'd considering creating a placeholder trusted_key_default_exit() with > perhaps pr_debug() statement acknowledging it getting called. > > Hmm.. if we had that I wonder if we could get away with __weak... Then > you would not need to assign anything. This is not through-out analyzed. > Tbh I'm not sure how module loader handles this type of scenario but > at least the placeholder function would make sense in any case. If you define a default exit function as __weak and expect trusted key sources to override it, you can only have one trust source at most in the compiled kernel and no boot-time selection would be possible. Cheers, Ahmad > > If abusing weak symbols was in-fact possible probably then the whole > idea of using static_call could be thrown to garbage bin but there's > now a lot of context here related on how module loader works linux > that I'm ignoring... > > BR, Jarkko > >
On Tue, 2023-10-10 at 16:19 +0200, Ahmad Fatoum wrote: > Hello Jarkko, > > On 10.10.23 15:49, Jarkko Sakkinen wrote: > > On Tue, 2023-10-10 at 18:44 +0530, Sumit Garg wrote: > > > On Tue, 10 Oct 2023 at 18:03, Jarkko Sakkinen <jarkko@kernel.org> wrote: > > > > > > > > On Fri, 2023-10-06 at 10:48 +0530, Sumit Garg wrote: > > > > > Static calls invocations aren't well supported from module __init and > > > > > __exit functions. Especially the static call from cleanup_trusted() led > > > > > to a crash on x86 kernel with CONFIG_DEBUG_VIRTUAL=y. > > > > > > > > > > However, the usage of static call invocations for trusted_key_init() > > > > > and trusted_key_exit() don't add any value from either a performance or > > > > > security perspective. Hence switch to use indirect function calls instead. > > > > > > > > > > Note here that although it will fix the current crash report, ultimately > > > > > the static call infrastructure should be fixed to either support its > > > > > future usage from module __init and __exit functions or not. > > > > > > > > > > Reported-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> > > > > > Link: https://lore.kernel.org/lkml/ZRhKq6e5nF%2F4ZIV1@fedora/#t > > > > > Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework") > > > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org> > > > > > --- > > > > > > > > > > Changes in v2: > > > > > - Polish commit message as per comments from Mimi > > > > > > > > > > security/keys/trusted-keys/trusted_core.c | 13 +++++-------- > > > > > 1 file changed, 5 insertions(+), 8 deletions(-) > > > > > > > > > > diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c > > > > > index c6fc50d67214..85fb5c22529a 100644 > > > > > --- a/security/keys/trusted-keys/trusted_core.c > > > > > +++ b/security/keys/trusted-keys/trusted_core.c > > > > > @@ -44,13 +44,12 @@ static const struct trusted_key_source trusted_key_sources[] = { > > > > > #endif > > > > > }; > > > > > > > > > > -DEFINE_STATIC_CALL_NULL(trusted_key_init, *trusted_key_sources[0].ops->init); > > > > > DEFINE_STATIC_CALL_NULL(trusted_key_seal, *trusted_key_sources[0].ops->seal); > > > > > DEFINE_STATIC_CALL_NULL(trusted_key_unseal, > > > > > *trusted_key_sources[0].ops->unseal); > > > > > DEFINE_STATIC_CALL_NULL(trusted_key_get_random, > > > > > *trusted_key_sources[0].ops->get_random); > > > > > -DEFINE_STATIC_CALL_NULL(trusted_key_exit, *trusted_key_sources[0].ops->exit); > > > > > +static void (*trusted_key_exit)(void); > > > > > static unsigned char migratable; > > > > > > > > > > enum { > > > > > @@ -359,19 +358,16 @@ static int __init init_trusted(void) > > > > > if (!get_random) > > > > > get_random = kernel_get_random; > > > > > > > > > > - static_call_update(trusted_key_init, > > > > > - trusted_key_sources[i].ops->init); > > > > > static_call_update(trusted_key_seal, > > > > > trusted_key_sources[i].ops->seal); > > > > > static_call_update(trusted_key_unseal, > > > > > trusted_key_sources[i].ops->unseal); > > > > > static_call_update(trusted_key_get_random, > > > > > get_random); > > > > > - static_call_update(trusted_key_exit, > > > > > - trusted_key_sources[i].ops->exit); > > > > > + trusted_key_exit = trusted_key_sources[i].ops->exit; > > > > > migratable = trusted_key_sources[i].ops->migratable; > > > > > > > > > > - ret = static_call(trusted_key_init)(); > > > > > + ret = trusted_key_sources[i].ops->init(); > > > > > if (!ret) > > > > > break; > > > > > } > > > > > @@ -388,7 +384,8 @@ static int __init init_trusted(void) > > > > > > > > > > static void __exit cleanup_trusted(void) > > > > > { > > > > > - static_call_cond(trusted_key_exit)(); > > > > > + if (trusted_key_exit) > > > > > + (*trusted_key_exit)(); > > > > > } > > > > > > > > > > late_initcall(init_trusted); > > > > > > > > Would it be less confusing to require trusted_key_exit from each? > > > > > > > > > > It is already required for each trust source to provide exit callback > > > but this NULL check was added via this fix [1] in case there isn't any > > > trust source present. > > > > > > [1] https://lkml.kernel.org/stable/20220126184155.220814-1-dave.kleikamp@oracle.com/ > > > > I'd considering creating a placeholder trusted_key_default_exit() with > > perhaps pr_debug() statement acknowledging it getting called. > > > > Hmm.. if we had that I wonder if we could get away with __weak... Then > > you would not need to assign anything. This is not through-out analyzed. > > Tbh I'm not sure how module loader handles this type of scenario but > > at least the placeholder function would make sense in any case. > > If you define a default exit function as __weak and expect trusted key sources > to override it, you can only have one trust source at most in the compiled > kernel and no boot-time selection would be possible. Right, got it, thank you. So, I still would consider trusted_key_default_exit() and assign that in the declaration to trusted_exit. BR, Jarkko
On Thu, 5 Oct 2023 at 22:18, Sumit Garg <sumit.garg@linaro.org> wrote: > > Static calls invocations aren't well supported from module __init and > __exit functions. Especially the static call from cleanup_trusted() led > to a crash on x86 kernel with CONFIG_DEBUG_VIRTUAL=y. > > However, the usage of static call invocations for trusted_key_init() > and trusted_key_exit() don't add any value from either a performance or > security perspective. Hence switch to use indirect function calls instead. I applied this patch to my tree, since it is a fix for the issue, and doesn't change any logic otherwise. However, I do note that the code logic is completely broken. It was broken before too, and apparently causes no problems, but it's still wrong. That's a separate issue, and would want a separate patch, but since I noticed it when applying this one, I'm replying here: > + trusted_key_exit = trusted_key_sources[i].ops->exit; > migratable = trusted_key_sources[i].ops->migratable; > > - ret = static_call(trusted_key_init)(); > + ret = trusted_key_sources[i].ops->init(); > if (!ret) > break; Note how this sets "trusted_key_exit" even when the ->init() function fails. Then we potentially do the module exit: > static void __exit cleanup_trusted(void) > { > - static_call_cond(trusted_key_exit)(); > + if (trusted_key_exit) > + (*trusted_key_exit)(); > } With an exit function that doesn't match a successful init() call. Now, *normally* this isn't a problem, because if the init() call fails, we'll go on to the next one, and if they *all* fail, we'll fail the module load, and we obviously won't call the cleanup_trusted() function at all. EXCEPT. We have this: /* * encrypted_keys.ko depends on successful load of this module even if * trusted key implementation is not found. */ if (ret == -ENODEV) return 0; so that init() may actually have failed, and we still succeed in loading the module, and now we will call that exit function to clean up something that was never successfully done. This hopefully doesn't matter in practice, and the cleanup function will just not do anything, but it is illogical and inconsistent. So I think it should be fixed. But as mentioned, this is a separate issue from the whole "you currently can't do static calls from __exit functions" issue. Linus
On Tue, 2023-10-10 at 11:28 -0700, Linus Torvalds wrote: > On Thu, 5 Oct 2023 at 22:18, Sumit Garg <sumit.garg@linaro.org> wrote: > > > > Static calls invocations aren't well supported from module __init and > > __exit functions. Especially the static call from cleanup_trusted() led > > to a crash on x86 kernel with CONFIG_DEBUG_VIRTUAL=y. > > > > However, the usage of static call invocations for trusted_key_init() > > and trusted_key_exit() don't add any value from either a performance or > > security perspective. Hence switch to use indirect function calls instead. > > I applied this patch to my tree, since it is a fix for the issue, and > doesn't change any logic otherwise. > > However, I do note that the code logic is completely broken. It was > broken before too, and apparently causes no problems, but it's still > wrong. > > That's a separate issue, and would want a separate patch, but since I > noticed it when applying this one, I'm replying here: > > > + trusted_key_exit = trusted_key_sources[i].ops->exit; > > migratable = trusted_key_sources[i].ops->migratable; > > > > - ret = static_call(trusted_key_init)(); > > + ret = trusted_key_sources[i].ops->init(); > > if (!ret) > > break; > > Note how this sets "trusted_key_exit" even when the ->init() function fails. Sumit, can you remind me why this continues *on any failure*? E.g. something like this would make more sense to me: ret = trusted_key_sources[i].ops->init(); if (!ret) { static_call_update(trusted_key_seal, trusted_key_sources[i].ops->seal); static_call_update(trusted_key_unseal, trusted_key_sources[i].ops->unseal); static_call_update(trusted_key_get_random, get_random); static_call_update(trusted_key_exit, trusted_key_sources[i].ops->exit); migratable = trusted_key_sources[i].ops->migratable; break; } if (ret != -ENODEV) break; ` BR, Jarkko
On Tue, 2023-10-10 at 22:05 +0300, Jarkko Sakkinen wrote: > On Tue, 2023-10-10 at 11:28 -0700, Linus Torvalds wrote: > > On Thu, 5 Oct 2023 at 22:18, Sumit Garg <sumit.garg@linaro.org> wrote: > > > > > > Static calls invocations aren't well supported from module __init and > > > __exit functions. Especially the static call from cleanup_trusted() led > > > to a crash on x86 kernel with CONFIG_DEBUG_VIRTUAL=y. > > > > > > However, the usage of static call invocations for trusted_key_init() > > > and trusted_key_exit() don't add any value from either a performance or > > > security perspective. Hence switch to use indirect function calls instead. > > > > I applied this patch to my tree, since it is a fix for the issue, and > > doesn't change any logic otherwise. > > > > However, I do note that the code logic is completely broken. It was > > broken before too, and apparently causes no problems, but it's still > > wrong. > > > > That's a separate issue, and would want a separate patch, but since I > > noticed it when applying this one, I'm replying here: > > > > > + trusted_key_exit = trusted_key_sources[i].ops->exit; > > > migratable = trusted_key_sources[i].ops->migratable; > > > > > > - ret = static_call(trusted_key_init)(); > > > + ret = trusted_key_sources[i].ops->init(); > > > if (!ret) > > > break; > > > > Note how this sets "trusted_key_exit" even when the ->init() function fails. > > Sumit, can you remind me why this continues *on any failure*? > > E.g. something like this would make more sense to me: > > ret = trusted_key_sources[i].ops->init(); > if (!ret) { > static_call_update(trusted_key_seal, trusted_key_sources[i].ops->seal); > static_call_update(trusted_key_unseal, trusted_key_sources[i].ops->unseal); > static_call_update(trusted_key_get_random, get_random); > static_call_update(trusted_key_exit, trusted_key_sources[i].ops->exit); Please ignore the line above :-) BR, Jarkko
On Tue, 10 Oct 2023 at 23:59, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Thu, 5 Oct 2023 at 22:18, Sumit Garg <sumit.garg@linaro.org> wrote: > > > > Static calls invocations aren't well supported from module __init and > > __exit functions. Especially the static call from cleanup_trusted() led > > to a crash on x86 kernel with CONFIG_DEBUG_VIRTUAL=y. > > > > However, the usage of static call invocations for trusted_key_init() > > and trusted_key_exit() don't add any value from either a performance or > > security perspective. Hence switch to use indirect function calls instead. > > I applied this patch to my tree, since it is a fix for the issue, and > doesn't change any logic otherwise. Thanks. > > However, I do note that the code logic is completely broken. It was > broken before too, and apparently causes no problems, but it's still > wrong. > > That's a separate issue, and would want a separate patch, but since I > noticed it when applying this one, I'm replying here: > > > + trusted_key_exit = trusted_key_sources[i].ops->exit; > > migratable = trusted_key_sources[i].ops->migratable; > > > > - ret = static_call(trusted_key_init)(); > > + ret = trusted_key_sources[i].ops->init(); > > if (!ret) > > break; > > Note how this sets "trusted_key_exit" even when the ->init() function fails. > > Then we potentially do the module exit: > > > static void __exit cleanup_trusted(void) > > { > > - static_call_cond(trusted_key_exit)(); > > + if (trusted_key_exit) > > + (*trusted_key_exit)(); > > } > > With an exit function that doesn't match a successful init() call. > > Now, *normally* this isn't a problem, because if the init() call > fails, we'll go on to the next one, and if they *all* fail, we'll fail > the module load, and we obviously won't call the cleanup_trusted() > function at all. > > EXCEPT. > > We have this: > > /* > * encrypted_keys.ko depends on successful load of this module even if > * trusted key implementation is not found. > */ > if (ret == -ENODEV) > return 0; > > so that init() may actually have failed, and we still succeed in > loading the module, and now we will call that exit function to clean > up something that was never successfully done. Here we consider -ENODEV as a success case since we don't want to block encrypted keys module loading since it can use user key as master key instead. > > This hopefully doesn't matter in practice, and the cleanup function > will just not do anything, but it is illogical and inconsistent. So I > think it should be fixed. Agree as the exit function won't do anything without the device being present but we should make it consistent. -Sumit > But as mentioned, this is a separate issue > from the whole "you currently can't do static calls from __exit > functions" issue. > > Linus
On Wed, 11 Oct 2023 at 00:35, Jarkko Sakkinen <jarkko@kernel.org> wrote: > > On Tue, 2023-10-10 at 11:28 -0700, Linus Torvalds wrote: > > On Thu, 5 Oct 2023 at 22:18, Sumit Garg <sumit.garg@linaro.org> wrote: > > > > > > Static calls invocations aren't well supported from module __init and > > > __exit functions. Especially the static call from cleanup_trusted() led > > > to a crash on x86 kernel with CONFIG_DEBUG_VIRTUAL=y. > > > > > > However, the usage of static call invocations for trusted_key_init() > > > and trusted_key_exit() don't add any value from either a performance or > > > security perspective. Hence switch to use indirect function calls instead. > > > > I applied this patch to my tree, since it is a fix for the issue, and > > doesn't change any logic otherwise. > > > > However, I do note that the code logic is completely broken. It was > > broken before too, and apparently causes no problems, but it's still > > wrong. > > > > That's a separate issue, and would want a separate patch, but since I > > noticed it when applying this one, I'm replying here: > > > > > + trusted_key_exit = trusted_key_sources[i].ops->exit; > > > migratable = trusted_key_sources[i].ops->migratable; > > > > > > - ret = static_call(trusted_key_init)(); > > > + ret = trusted_key_sources[i].ops->init(); > > > if (!ret) > > > break; > > > > Note how this sets "trusted_key_exit" even when the ->init() function fails. > > Sumit, can you remind me why this continues *on any failure*? We should give other trust sources a chance to register for trusted keys if the primary one fails. -Sumit > > E.g. something like this would make more sense to me: > > ret = trusted_key_sources[i].ops->init(); > if (!ret) { > static_call_update(trusted_key_seal, trusted_key_sources[i].ops->seal); > static_call_update(trusted_key_unseal, trusted_key_sources[i].ops->unseal); > static_call_update(trusted_key_get_random, get_random); > static_call_update(trusted_key_exit, trusted_key_sources[i].ops->exit); > migratable = trusted_key_sources[i].ops->migratable; > break; > } > > if (ret != -ENODEV) > break; > ` > BR, Jarkko
diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c index c6fc50d67214..85fb5c22529a 100644 --- a/security/keys/trusted-keys/trusted_core.c +++ b/security/keys/trusted-keys/trusted_core.c @@ -44,13 +44,12 @@ static const struct trusted_key_source trusted_key_sources[] = { #endif }; -DEFINE_STATIC_CALL_NULL(trusted_key_init, *trusted_key_sources[0].ops->init); DEFINE_STATIC_CALL_NULL(trusted_key_seal, *trusted_key_sources[0].ops->seal); DEFINE_STATIC_CALL_NULL(trusted_key_unseal, *trusted_key_sources[0].ops->unseal); DEFINE_STATIC_CALL_NULL(trusted_key_get_random, *trusted_key_sources[0].ops->get_random); -DEFINE_STATIC_CALL_NULL(trusted_key_exit, *trusted_key_sources[0].ops->exit); +static void (*trusted_key_exit)(void); static unsigned char migratable; enum { @@ -359,19 +358,16 @@ static int __init init_trusted(void) if (!get_random) get_random = kernel_get_random; - static_call_update(trusted_key_init, - trusted_key_sources[i].ops->init); static_call_update(trusted_key_seal, trusted_key_sources[i].ops->seal); static_call_update(trusted_key_unseal, trusted_key_sources[i].ops->unseal); static_call_update(trusted_key_get_random, get_random); - static_call_update(trusted_key_exit, - trusted_key_sources[i].ops->exit); + trusted_key_exit = trusted_key_sources[i].ops->exit; migratable = trusted_key_sources[i].ops->migratable; - ret = static_call(trusted_key_init)(); + ret = trusted_key_sources[i].ops->init(); if (!ret) break; } @@ -388,7 +384,8 @@ static int __init init_trusted(void) static void __exit cleanup_trusted(void) { - static_call_cond(trusted_key_exit)(); + if (trusted_key_exit) + (*trusted_key_exit)(); } late_initcall(init_trusted);