Message ID | 20231007170448.505487-1-masahiroy@kernel.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 x8csp1025518vqo; Sat, 7 Oct 2023 10:05:03 -0700 (PDT) X-Google-Smtp-Source: AGHT+IESM0AkirKDlbYT3qPUDve/IEN50DkkpgqdpzXH8icYIETpmlMosr3k8oMnM/9eREodb858 X-Received: by 2002:a17:90b:224d:b0:274:566a:3477 with SMTP id hk13-20020a17090b224d00b00274566a3477mr10084802pjb.39.1696698303519; Sat, 07 Oct 2023 10:05:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696698303; cv=none; d=google.com; s=arc-20160816; b=ZRT8Hx0VLiGGQ+jYZuy/smfARjc9ZcHnwcWo+n1GjBJtuRxn6bHvinaZieSwVh+dGk DNvNtwvKm7Ym3uc1C6gUctYhSbuDeU4YTOwrfyjKaVEyvM6D9bi0F17N4leTOtw4f+62 bRmM2pH54PhxGjjEt5BWBA49wqPVyCmKySiXOU82H7W9WEsKXIdGUpSqfP8nLUq6y+dG SK6pTQ8E011tnWvW4/OrFied/UFLy4MO31ULQqLH49zYWCFSFxcrCwlOsA18GjkNfYdD OE/YZv38gdC6Hv3+0VDjzqK+rF+acEeUvqi5wVKaH+fiY55nwAW7fJntj2K3+AVisIjD wo/A== 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=+cNCiC/eyaq00gUbEallfBQkCZDVZ4YiM1X68Ma2ZDA=; fh=Mw/LznQKwenJ3ald+1YgmXerMD3yRTh+GSxPKaa8Fs0=; b=e/1UGn3hkZrEFyoeTai3Uh8G9BoqRIzP1yGpQ51rgm7fWpwQJ6BtHKGXp0sRjS9zxy gPPnfNcGCVGMqXdnXBxgE2AdpH4iJmnrqze3WK1B47Am8aJqXLW9HqaGLvoE2TsxYBMV wVYnh+sSE4Lm/xnEwmSZWPVoj1wlRvOfXFnyIIQTEBSl8mbl4lQTN3j+auALAw9plcLv R8HQkCzyssVbXAjoXQLY4ZnQvjVGGwHjyNk0kVshVVs2oMJvPXbEnkRmLbPotVXqK5gf 0BFThgEZEZoA+l+8F/2RcNrw9Y8FlTtlkCFikdiO/r4RXPYt5q2f1gGWTNqw8frPSLrb 7y/Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ne3VlCVV; 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=kernel.org Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id e10-20020a17090a804a00b002792440fc3bsi719811pjw.185.2023.10.07.10.05.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 07 Oct 2023 10:05:03 -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=@kernel.org header.s=k20201202 header.b=ne3VlCVV; 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=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id E9049809788E; Sat, 7 Oct 2023 10:05:02 -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 S1344083AbjJGRE7 (ORCPT <rfc822;pusanteemu@gmail.com> + 17 others); Sat, 7 Oct 2023 13:04:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56734 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344032AbjJGRE6 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 7 Oct 2023 13:04:58 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D6921B9; Sat, 7 Oct 2023 10:04:55 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 22F07C433C8; Sat, 7 Oct 2023 17:04:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1696698295; bh=5rWN3r1QrWbZPdwY53XXoqrpI9vkxw4GAZMoimstNTU=; h=From:To:Cc:Subject:Date:From; b=ne3VlCVVWtdJlPXT1Sksj5UMIr8o7iegZVtoYOu+WNb8oD72PHoQ0DS3n7xxd451P dKdElA/aK5liU8cGmISK7mIQ9tWuwrGKuVcwzRtyy7sOXQ8HMMOE/ptiKzqX7HTmTW Ki0wW+XN3u0oZ1BDbkug60VpfBjvKSyWoH2aE0nXbf45BHbWtmw7WcA3mreTtwoLea 85+bV00WxR29ecLxzHVzx/s36oLAQ2oZbHqIs6fwmQY1K4q+ynlVtxQf+p+FRy1lpG blsa/RQzXTZe2pisEPrHwh3T9zohUTugXF2q9o1uW+YHKhrolJy1lBesq+GXCoJzLO WiWvd4yF+jkgw== From: Masahiro Yamada <masahiroy@kernel.org> To: linux-kbuild@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Masahiro Yamada <masahiroy@kernel.org>, Bhupesh Sharma <bhsharma@redhat.com>, Daniel Thompson <daniel.thompson@linaro.org>, Jens Wiklander <jens.wiklander@linaro.org>, Nathan Chancellor <nathan@kernel.org>, Nick Desaulniers <ndesaulniers@google.com>, Nicolas Schier <nicolas@fjasle.eu>, Sumit Garg <sumit.garg@linaro.org> Subject: [PATCH 1/5] modpost: fix tee MODULE_DEVICE_TABLE built on big endian host Date: Sun, 8 Oct 2023 02:04:44 +0900 Message-Id: <20231007170448.505487-1-masahiroy@kernel.org> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, 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]); Sat, 07 Oct 2023 10:05:02 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779117120555903291 X-GMAIL-MSGID: 1779117120555903291 |
Series |
[1/5] modpost: fix tee MODULE_DEVICE_TABLE built on big endian host
|
|
Commit Message
Masahiro Yamada
Oct. 7, 2023, 5:04 p.m. UTC
When MODULE_DEVICE_TABLE(tee, ) is built on a host with a different
endianness from the target architecture, it results in an incorrect
MODULE_ALIAS().
For example, see a case where drivers/char/hw_random/optee-rng.c
is built as a module.
If you build it on a little endian host, you will get the correct
MODULE_ALIAS:
$ grep MODULE_ALIAS drivers/char/hw_random/optee-rng.mod.c
MODULE_ALIAS("tee:ab7a617c-b8e7-4d8f-8301-d09b61036b64*");
However, if you build it on a big endian host, you will get a wrong
MODULE_ALIAS:
$ grep MODULE_ALIAS drivers/char/hw_random/optee-rng.mod.c
MODULE_ALIAS("tee:646b0361-9bd0-0183-8f4d-e7b87c617aab*");
This issue has been unnoticed because the ARM kernel is most likely built
on a little endian host (cross-build on x86 or native-build on ARM).
The uuid field must not be reversed because uuid_t is an array of __u8.
Fixes: 0fc1db9d1059 ("tee: add bus driver framework for TEE based devices")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
---
scripts/mod/file2alias.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
Comments
Hi Masahiro, On Sat, 7 Oct 2023 at 22:34, Masahiro Yamada <masahiroy@kernel.org> wrote: > > When MODULE_DEVICE_TABLE(tee, ) is built on a host with a different > endianness from the target architecture, it results in an incorrect > MODULE_ALIAS(). > > For example, see a case where drivers/char/hw_random/optee-rng.c > is built as a module. > > If you build it on a little endian host, you will get the correct > MODULE_ALIAS: > > $ grep MODULE_ALIAS drivers/char/hw_random/optee-rng.mod.c > MODULE_ALIAS("tee:ab7a617c-b8e7-4d8f-8301-d09b61036b64*"); > > However, if you build it on a big endian host, you will get a wrong > MODULE_ALIAS: > > $ grep MODULE_ALIAS drivers/char/hw_random/optee-rng.mod.c > MODULE_ALIAS("tee:646b0361-9bd0-0183-8f4d-e7b87c617aab*"); > > This issue has been unnoticed because the ARM kernel is most likely built > on a little endian host (cross-build on x86 or native-build on ARM). > > The uuid field must not be reversed because uuid_t is an array of __u8. > To me it wasn't obvious that DEF_FIELD() has certain endianness limitations. > Fixes: 0fc1db9d1059 ("tee: add bus driver framework for TEE based devices") > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> > --- > > scripts/mod/file2alias.c | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c > index 7056751c29b1..70bf6a2f585c 100644 > --- a/scripts/mod/file2alias.c > +++ b/scripts/mod/file2alias.c > @@ -1348,13 +1348,13 @@ static int do_typec_entry(const char *filename, void *symval, char *alias) > /* Looks like: tee:uuid */ > static int do_tee_entry(const char *filename, void *symval, char *alias) > { > - DEF_FIELD(symval, tee_client_device_id, uuid); As you have mentioned in patch #3: the limitations of TO_NATIVE(), if you can update comments for DEF_FIELD() as well to make it clear that it doesn't support byte arrays/strings would be helpful. I think the following check that you have introduced in patch #3 can still be bypassed for byte arrays/strings. + _Static_assert(sizeof(x) == 1 || sizeof(x) == 2 || \ + sizeof(x) == 4 || sizeof(x) == 8, "bug"); BTW, for this fix feel free to add: Reviewed-by: Sumit Garg <sumit.garg@linaro.org> -Sumit > + DEF_FIELD_ADDR(symval, tee_client_device_id, uuid); > > sprintf(alias, "tee:%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x", > - uuid.b[0], uuid.b[1], uuid.b[2], uuid.b[3], uuid.b[4], > - uuid.b[5], uuid.b[6], uuid.b[7], uuid.b[8], uuid.b[9], > - uuid.b[10], uuid.b[11], uuid.b[12], uuid.b[13], uuid.b[14], > - uuid.b[15]); > + uuid->b[0], uuid->b[1], uuid->b[2], uuid->b[3], uuid->b[4], > + uuid->b[5], uuid->b[6], uuid->b[7], uuid->b[8], uuid->b[9], > + uuid->b[10], uuid->b[11], uuid->b[12], uuid->b[13], uuid->b[14], > + uuid->b[15]); > > add_wildcard(alias); > return 1; > -- > 2.39.2 >
On Mon, Oct 9, 2023 at 3:27 PM Sumit Garg <sumit.garg@linaro.org> wrote: > > Hi Masahiro, > > On Sat, 7 Oct 2023 at 22:34, Masahiro Yamada <masahiroy@kernel.org> wrote: > > > > When MODULE_DEVICE_TABLE(tee, ) is built on a host with a different > > endianness from the target architecture, it results in an incorrect > > MODULE_ALIAS(). > > > > For example, see a case where drivers/char/hw_random/optee-rng.c > > is built as a module. > > > > If you build it on a little endian host, you will get the correct > > MODULE_ALIAS: > > > > $ grep MODULE_ALIAS drivers/char/hw_random/optee-rng.mod.c > > MODULE_ALIAS("tee:ab7a617c-b8e7-4d8f-8301-d09b61036b64*"); > > > > However, if you build it on a big endian host, you will get a wrong > > MODULE_ALIAS: > > > > $ grep MODULE_ALIAS drivers/char/hw_random/optee-rng.mod.c > > MODULE_ALIAS("tee:646b0361-9bd0-0183-8f4d-e7b87c617aab*"); > > > > This issue has been unnoticed because the ARM kernel is most likely built > > on a little endian host (cross-build on x86 or native-build on ARM). > > > > The uuid field must not be reversed because uuid_t is an array of __u8. > > > > To me it wasn't obvious that DEF_FIELD() has certain endianness limitations. > > > Fixes: 0fc1db9d1059 ("tee: add bus driver framework for TEE based devices") > > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> > > --- > > > > scripts/mod/file2alias.c | 10 +++++----- > > 1 file changed, 5 insertions(+), 5 deletions(-) > > > > diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c > > index 7056751c29b1..70bf6a2f585c 100644 > > --- a/scripts/mod/file2alias.c > > +++ b/scripts/mod/file2alias.c > > @@ -1348,13 +1348,13 @@ static int do_typec_entry(const char *filename, void *symval, char *alias) > > /* Looks like: tee:uuid */ > > static int do_tee_entry(const char *filename, void *symval, char *alias) > > { > > - DEF_FIELD(symval, tee_client_device_id, uuid); > > As you have mentioned in patch #3: the limitations of TO_NATIVE(), if > you can update comments for DEF_FIELD() as well to make it clear that > it doesn't support byte arrays/strings would be helpful. I think the > following check that you have introduced in patch #3 can still be > bypassed for byte arrays/strings. > > + _Static_assert(sizeof(x) == 1 || sizeof(x) == 2 || \ > + sizeof(x) == 4 || sizeof(x) == 8, "bug"); I am afraid you missed the point. bswap_2, bswap_4, bswap_8 do not take a pointer. If you pass an array or a string, it will result in a build error due to the compiler's prototype checking. The kbuild test robot will catch a build error anyway. "You cannot build it in the first place" is better than a comment. > BTW, for this fix feel free to add: > > Reviewed-by: Sumit Garg <sumit.garg@linaro.org> > > -Sumit > > > + DEF_FIELD_ADDR(symval, tee_client_device_id, uuid); > > > > sprintf(alias, "tee:%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x", > > - uuid.b[0], uuid.b[1], uuid.b[2], uuid.b[3], uuid.b[4], > > - uuid.b[5], uuid.b[6], uuid.b[7], uuid.b[8], uuid.b[9], > > - uuid.b[10], uuid.b[11], uuid.b[12], uuid.b[13], uuid.b[14], > > - uuid.b[15]); > > + uuid->b[0], uuid->b[1], uuid->b[2], uuid->b[3], uuid->b[4], > > + uuid->b[5], uuid->b[6], uuid->b[7], uuid->b[8], uuid->b[9], > > + uuid->b[10], uuid->b[11], uuid->b[12], uuid->b[13], uuid->b[14], > > + uuid->b[15]); > > > > add_wildcard(alias); > > return 1; > > -- > > 2.39.2 > > -- Best Regards Masahiro Yamada
On Mon, 9 Oct 2023 at 12:27, Masahiro Yamada <masahiroy@kernel.org> wrote: > > On Mon, Oct 9, 2023 at 3:27 PM Sumit Garg <sumit.garg@linaro.org> wrote: > > > > Hi Masahiro, > > > > On Sat, 7 Oct 2023 at 22:34, Masahiro Yamada <masahiroy@kernel.org> wrote: > > > > > > When MODULE_DEVICE_TABLE(tee, ) is built on a host with a different > > > endianness from the target architecture, it results in an incorrect > > > MODULE_ALIAS(). > > > > > > For example, see a case where drivers/char/hw_random/optee-rng.c > > > is built as a module. > > > > > > If you build it on a little endian host, you will get the correct > > > MODULE_ALIAS: > > > > > > $ grep MODULE_ALIAS drivers/char/hw_random/optee-rng.mod.c > > > MODULE_ALIAS("tee:ab7a617c-b8e7-4d8f-8301-d09b61036b64*"); > > > > > > However, if you build it on a big endian host, you will get a wrong > > > MODULE_ALIAS: > > > > > > $ grep MODULE_ALIAS drivers/char/hw_random/optee-rng.mod.c > > > MODULE_ALIAS("tee:646b0361-9bd0-0183-8f4d-e7b87c617aab*"); > > > > > > This issue has been unnoticed because the ARM kernel is most likely built > > > on a little endian host (cross-build on x86 or native-build on ARM). > > > > > > The uuid field must not be reversed because uuid_t is an array of __u8. > > > > > > > To me it wasn't obvious that DEF_FIELD() has certain endianness limitations. > > > > > Fixes: 0fc1db9d1059 ("tee: add bus driver framework for TEE based devices") > > > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> > > > --- > > > > > > scripts/mod/file2alias.c | 10 +++++----- > > > 1 file changed, 5 insertions(+), 5 deletions(-) > > > > > > diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c > > > index 7056751c29b1..70bf6a2f585c 100644 > > > --- a/scripts/mod/file2alias.c > > > +++ b/scripts/mod/file2alias.c > > > @@ -1348,13 +1348,13 @@ static int do_typec_entry(const char *filename, void *symval, char *alias) > > > /* Looks like: tee:uuid */ > > > static int do_tee_entry(const char *filename, void *symval, char *alias) > > > { > > > - DEF_FIELD(symval, tee_client_device_id, uuid); > > > > As you have mentioned in patch #3: the limitations of TO_NATIVE(), if > > you can update comments for DEF_FIELD() as well to make it clear that > > it doesn't support byte arrays/strings would be helpful. I think the > > following check that you have introduced in patch #3 can still be > > bypassed for byte arrays/strings. > > > > + _Static_assert(sizeof(x) == 1 || sizeof(x) == 2 || \ > > + sizeof(x) == 4 || sizeof(x) == 8, "bug"); > > > > > I am afraid you missed the point. > > bswap_2, bswap_4, bswap_8 do not take a pointer. > > If you pass an array or a string, > it will result in a build error > due to the compiler's prototype checking. > > The kbuild test robot will catch a build error anyway. > I see your point. > > "You cannot build it in the first place" > is better than a comment. > That's fine with me as long as it's a build problem. -Sumit > > > > > > > > > > > BTW, for this fix feel free to add: > > > > Reviewed-by: Sumit Garg <sumit.garg@linaro.org> > > > > -Sumit > > > > > + DEF_FIELD_ADDR(symval, tee_client_device_id, uuid); > > > > > > sprintf(alias, "tee:%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x", > > > - uuid.b[0], uuid.b[1], uuid.b[2], uuid.b[3], uuid.b[4], > > > - uuid.b[5], uuid.b[6], uuid.b[7], uuid.b[8], uuid.b[9], > > > - uuid.b[10], uuid.b[11], uuid.b[12], uuid.b[13], uuid.b[14], > > > - uuid.b[15]); > > > + uuid->b[0], uuid->b[1], uuid->b[2], uuid->b[3], uuid->b[4], > > > + uuid->b[5], uuid->b[6], uuid->b[7], uuid->b[8], uuid->b[9], > > > + uuid->b[10], uuid->b[11], uuid->b[12], uuid->b[13], uuid->b[14], > > > + uuid->b[15]); > > > > > > add_wildcard(alias); > > > return 1; > > > -- > > > 2.39.2 > > > > > > > -- > Best Regards > Masahiro Yamada
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c index 7056751c29b1..70bf6a2f585c 100644 --- a/scripts/mod/file2alias.c +++ b/scripts/mod/file2alias.c @@ -1348,13 +1348,13 @@ static int do_typec_entry(const char *filename, void *symval, char *alias) /* Looks like: tee:uuid */ static int do_tee_entry(const char *filename, void *symval, char *alias) { - DEF_FIELD(symval, tee_client_device_id, uuid); + DEF_FIELD_ADDR(symval, tee_client_device_id, uuid); sprintf(alias, "tee:%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x", - uuid.b[0], uuid.b[1], uuid.b[2], uuid.b[3], uuid.b[4], - uuid.b[5], uuid.b[6], uuid.b[7], uuid.b[8], uuid.b[9], - uuid.b[10], uuid.b[11], uuid.b[12], uuid.b[13], uuid.b[14], - uuid.b[15]); + uuid->b[0], uuid->b[1], uuid->b[2], uuid->b[3], uuid->b[4], + uuid->b[5], uuid->b[6], uuid->b[7], uuid->b[8], uuid->b[9], + uuid->b[10], uuid->b[11], uuid->b[12], uuid->b[13], uuid->b[14], + uuid->b[15]); add_wildcard(alias); return 1;