linux-kernel - Re: [PATCH v11 09/14] module: Move kallsyms support into a separate file

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 3 Jul 2022 09:23:05 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Aaron Tomlin <atomlin@...hat.com>
Cc:     Luis Chamberlain <mcgrof@...nel.org>, christophe.leroy@...roup.eu,
        cl@...ux.com, mbenes@...e.cz, akpm@...ux-foundation.org,
        jeyu@...nel.org, linux-kernel@...r.kernel.org,
        linux-modules@...r.kernel.org, void@...ifault.com,
        atomlin@...mlin.com, allen.lkml@...il.com, joe@...ches.com,
        msuchanek@...e.de, oleksandr@...alenko.name,
        jason.wessel@...driver.com, pmladek@...e.com,
        daniel.thompson@...aro.org, hch@...radead.org,
        Chuck Lever III <chuck.lever@...cle.com>
Subject: Re: [PATCH v11 09/14] module: Move kallsyms support into a separate
 file

On Sun, 3 Jul 2022 09:33:24 +0100
Aaron Tomlin <atomlin@...hat.com> wrote:

> On Fri 2022-07-01 15:34 -0700, Luis Chamberlain wrote:
> > Poke, did you get to implement this yet?  
> 
> Hi Luis, Steve,
> 
> Firstly, apologies for the delay.
> 
> I believe I found the issue:
> 
> diff --git a/kernel/module/kallsyms.c b/kernel/module/kallsyms.c
> index 1b0780e20aab..84808706af5c 100644
> --- a/kernel/module/kallsyms.c
> +++ b/kernel/module/kallsyms.c
> @@ -197,7 +197,7 @@ void add_kallsyms(struct module *mod, const struct load_info *info)
>                             mod->kallsyms->typetab[i];
>                         dst[ndst] = src[i];
>                         dst[ndst++].st_name = s - mod->core_kallsyms.strtab;
> -                       s += strscpy(s, &mod->kallsyms->strtab[src[i].st_name],
> +                       s += strlcpy(s, &mod->kallsyms->strtab[src[i].st_name],
>                                      KSYM_NAME_LEN) + 1;
>                 }
>         }
> 
> That being said, I need to examine the precise differences between each
> implementation; albeit, I believe we can revert this particular change. I
> will send a patch for a wider discussion shortly.
> 
>  - Before
> 
>       $ grep -a -E '^[0-9a-f]{16} [^a-z].*\[virtio_console\]' /proc/kallsyms
>       0000000000000000  notifier_del_vio      [virtio_console]
>       0000000000000000  show_port_name        [virtio_console]
>       0000000000000000  port_debugfs_open     [virtio_console]
> 
>  - After the above modification
> 
>       $ grep -a -E '^[0-9a-f]{16} [^a-z].*\[virtio_console\]' /proc/kallsyms
>       $ grep -a -m 3 -E '^[0-9a-f]{16} [a-z].*\[virtio_console\]' /proc/kallsyms
>       0000000000000000 t notifier_del_vio     [virtio_console]
>       0000000000000000 t show_port_name       [virtio_console]
>       0000000000000000 t port_debugfs_open    [virtio_console]
> 
> 

BTW, *NEVER* modify code that you are moving. Really, *NEVER* do that!

It makes debugging much more difficult, like in this very case.

*ALWAYS* have the moving of code be a separate patch. Keep as most
identical as humanly possible. Even keep white space errors the same!
You can add a clean up patch before or after the move. But never do it
as one patch!

You even stated "no functional change" which was a lie. Converting
strlcpy() to strscpy() *is* a functional change!

-- Steve