lkml.org 
[lkml]   [2023]   [Oct]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 1/5] modpost: fix tee MODULE_DEVICE_TABLE built on big endian host
    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

    \
     
     \ /
      Last update: 2023-10-09 08:58    [W:5.521 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site