Re: [PATCH] modpost: abort if a module name is too long

[Wanlong Gao]

On 2017/6/22 22:25, Jessica Yu wrote:
> +++ Wanlong Gao [22/06/17 09:11 +0800]:
>>
>>
>> On 2017/6/22 0:09, Jessica Yu wrote:
>>> +++ Jessica Yu [06/06/17 20:41 -0700]:
>>>> +++ Wanlong Gao [06/06/17 09:07 +0800]:
>>>>>
>>>>>
>>>>> On 2017/6/5 10:09, Jessica Yu wrote:
>>>>>> +++ Wanlong Gao [02/06/17 11:04 +0800]:
>>>>>>>
>>>>>>>
>>>>>>> On 2017/6/2 7:23, Jessica Yu wrote:
>>>>>>>> +++ Wanlong Gao [31/05/17 11:48 +0800]:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2017/5/31 11:30, Jessica Yu wrote:
>>>>>>>>>> +++ Wanlong Gao [31/05/17 10:23 +0800]:
>>>>>>>>>>> Hi Jessica,
>>>>>>>>>>>
>>>>>>>>>>> On 2017/5/29 17:10, Jessica Yu wrote:
>>>>>>>>>>>> +++ Xie XiuQi [20/05/17 15:46 +0800]:
>>>>>>>>>>>>> From: Wanlong Gao <gaowanlong@xxxxxxxxxx>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Module name has a limited length, but currently the build system
>>>>>>>>>>>>> allows the build finishing even if the module name is too long.
>>>>>>>>>>>>>
>>>>>>>>>>>>> CC      /root/kprobe_example/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz.mod.o
>>>>>>>>>>>>> /root/kprobe_example/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz.mod.c:9:2:
>>>>>>>>>>>>> warning: initializer-string for array of chars is too long [enabled by default]
>>>>>>>>>>>>> .name = KBUILD_MODNAME,
>>>>>>>>>>>>> ^
>>>>>>>>>>>>>
>>>>>>>>>>>>> but it's merely a warning.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This patch adds the check of the module name length in modpost and stops
>>>>>>>>>>>>> the build properly.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Signed-off-by: Wanlong Gao <gaowanlong@xxxxxxxxxx>
>>>>>>>>>>>>> Signed-off-by: Xie XiuQi <xiexiuqi@xxxxxxxxxx>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>> scripts/mod/modpost.c | 11 +++++++++++
>>>>>>>>>>>>> 1 file changed, 11 insertions(+)
>>>>>>>>>>>>>
>>>>>>>>>>>>> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
>>>>>>>>>>>>> index 30d752a..db11c57 100644
>>>>>>>>>>>>> --- a/scripts/mod/modpost.c
>>>>>>>>>>>>> +++ b/scripts/mod/modpost.c
>>>>>>>>>>>>> @@ -2166,6 +2166,17 @@ static int add_versions(struct buffer *b, struct module *mod)
>>>>>>>>>>>>> {
>>>>>>>>>>>>>    struct symbol *s, *exp;
>>>>>>>>>>>>>    int err = 0;
>>>>>>>>>>>>> +    const char *mod_name;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +    mod_name = strrchr(mod->name, '/');
>>>>>>>>>>>>> +    if (mod_name == NULL)
>>>>>>>>>>>>> +        mod_name = mod->name;
>>>>>>>>>>>>> +    else
>>>>>>>>>>>>> +        mod_name++;
>>>>>>>>>>>>> +    if (strlen(mod_name) >= MODULE_NAME_LEN) {
>>>>>>>>>>>>> +        merror("module name is too long [%s.ko]\n", mod->name);
>>>>>>>>>>>>> +        return 1;
>>>>>>>>>>>>> +    }
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Xie,
>>>>>>>>>>>>
>>>>>>>>>>>> This check shouldn't be in add_versions() (which does something else entirely),
>>>>>>>>>>>> it should probably be put in a separate helper function called from main. But
>>>>>>>>>>>> I'm not a big fan of the extra string manipulation to do something this simple.
>>>>>>>>>>>>
>>>>>>>>>>>> I think this check can be vastly simplified, how about something like the
>>>>>>>>>>>> following?
>>>>>>>>>>>
>>>>>>>>>>> This looks better, would you apply your following patch?
>>>>>>>>>>>
>>>>>>>>>>> Reviewed-by: Wanlong Gao <gaowanlong@xxxxxxxxxx>
>>>>>>>>>>> Tested-by: Wanlong Gao <gaowanlong@xxxxxxxxxx>
>>>>>>>>>>
>>>>>>>>>> Sure, thanks for testing. I'll go ahead and format this into a proper
>>>>>>>>>> patch and resend.
>>>>>>>>>
>>>>>>>>> Please wait, I just found that this patch makes the built module can't
>>>>>>>>> be inserted by the following error:
>>>>>>>>>
>>>>>>>>> # insmod abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabc.ko
>>>>>>>>> insmod: ERROR: could not insert module abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabc.ko: Invalid parameters
>>>>>>>>>
>>>>>>>>> # dmesg
>>>>>>>>> abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabc: Unknown symbol __fentry__ (err -22)
>>>>>>>>
>>>>>>>> Hm, I am unable to reproduce this. It looks like __fentry__ is missing
>>>>>>>> from your kernel, you may have a mismatch between the kernel config
>>>>>>>> that you're running and the config you are using to build the module.
>>>>>>>> In other words, it seems like you might have built the module with
>>>>>>>> CONFIG_FTRACE but built the kernel without.
>>>>>>>>
>>>>>>>> Few questions -
>>>>>>>>
>>>>>>>> What is the output of running `grep __fentry__ /proc/kallsyms`?
>>>>>>>>
>>>>>>>
>>>>>>> Sure it has.
>>>>>>>
>>>>>>>> Does your module correspond to the running kernel version?
>>>>>>>
>>>>>>> Sure.
>>>>>>>
>>>>>>>>
>>>>>>>> Do you have CONFIG_FTRACE/FUNCTION_TRACER enabled in your running
>>>>>>>> kernel?
>>>>>>>>
>>>>>>>
>>>>>>> Sure.
>>>>>>>
>>>>>>>
>>>>>>>> Is that the full dmesg output (are there any other error messages)?
>>>>>>>
>>>>>>> Even when I compiled the kernel with your patch, the kernel module load
>>>>>>> failed at the boot time with the following error:
>>>>>>>
>>>>>>> [    1.656708] libcrc32c: no symbol version for __fentry__
>>>>>>> [    1.656709] libcrc32c: Unknown symbol __fentry__ (err -22)
>>>>>>>
>>>>>>> But my above patch in add_versions() doesn't have such problem, I've no
>>>>>>> idea why. Maybe your patch breaks some sections?
>>>>>>
>>>>>> Hm, I am still unable to reproduce this on my system with modversions
>>>>>> enabled and the -rc2 kernel. But judging by the errno (-22) it looks
>>>>>> like this is failing in check_version()/resolve_symbol() for you,
>>>>>> which leads me to think that this is somehow messing with the
>>>>>> __versions table generated by modpost (not sure why).
>>>>>>
>>>>>> Does the  ____versions[] array in the generated *.mod.c file for your
>>>>>> test module look different with and without the patch? Also: what
>>>>>> version of gcc and binutils are you using, and what kernel version are
>>>>>> you testing on?
>>>>>
>>>>> The *.mod.c file are same except the added __modname_test section, the gcc
>>>>> ,binutils and kernel are all from centos 7.2 (3.10.0-327).
>>>>
>>>> Thanks for the additional info. Just FYI, I'm going to be out this
>>>> week and part of next week due to travelling, but I'll be able to take
>>>> another look at this next Thurs/Fri. If we can't resolve the issue, we
>>>> can just work on your original patch.
>>>
>>> Thanks for your patience, I've just moved abroad and getting to stable
>>> internet has been a challenge :-/
>>>
>>> Here's my last attempt at fixing the BUILD_BUG_ON patch (I am not sure
>>> why it seems to be messing with the __versions table on your setup,
>>> perhaps it is related to .discard usage?).
>>>
>>> Do either of the patches below work on your setup? (try one or the
>>> other and let me know if either of them work..)
>>
>> Sorry to say that neither ;< It seems not to add section in mod.c
>> is more safe.
> 
> No problem, thanks for verifying! I originally liked the build bug
> patch because it worked directly with the in-kernel module name,
> instead of the filename (they can differ slightly, but the number of
> chars should remain the same anyway..). In any case, could you modify
> your original patch to put the modname check in a separate function,
> maybe named check_modname_len(), and have it be called before
> check_exports()?


Sure, will send V2 ;)

Thanks,
Wanlong Gao

> 
> Thanks!
> 
> Jessica
> 
> 
> .
>