Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751629AbdFFBHb (ORCPT ); Mon, 5 Jun 2017 21:07:31 -0400 Received: from szxga01-in.huawei.com ([45.249.212.187]:7317 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751615AbdFFBH3 (ORCPT ); Mon, 5 Jun 2017 21:07:29 -0400 Subject: Re: [PATCH] modpost: abort if a module name is too long To: Jessica Yu References: <1495266381-14755-1-git-send-email-xiexiuqi@huawei.com> <20170529091007.e3zhsasmcxhzexx6@jeyu> <20170531033042.mtrmcj6odvn2bmxs@jeyu> <20170601232303.qtc6eldvl6xh2ln6@jeyu> <61160239-31e2-8bfe-766b-4570922c0726@huawei.com> <20170605020958.mfmftfjuvyawmgfl@jeyu> CC: , Xie XiuQi , , , , , , From: Wanlong Gao Message-ID: <59971487-9896-2681-086d-294c0cc5c2aa@huawei.com> Date: Tue, 6 Jun 2017 09:07:04 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20170605020958.mfmftfjuvyawmgfl@jeyu> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.97.93] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.5936004F.009B,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 072a57e691b18536369218de3e782316 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 6361 Lines: 185 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 >>>>>>>> >>>>>>>> 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 >>>>>>>> Signed-off-by: Xie XiuQi >>>>>>>> --- >>>>>>>> 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 >>>>>> Tested-by: Wanlong Gao >>>>> >>>>> 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, Wanlong Gao > > If you could also send me off-list the *.mod.c files generated by > modpost with and without the patch applied, that'd also help. > > Thanks, > > Jessica > >>>>>>> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c >>>>>>> index 48397fe..bb09fc7 100644 >>>>>>> --- a/scripts/mod/modpost.c >>>>>>> +++ b/scripts/mod/modpost.c >>>>>>> @@ -2139,6 +2139,9 @@ static void add_header(struct buffer *b, struct module *mod) >>>>>>> "#endif\n"); >>>>>>> buf_printf(b, "\t.arch = MODULE_ARCH_INIT,\n"); >>>>>>> buf_printf(b, "};\n"); >>>>>>> + buf_printf(b, "\n"); >>>>>>> + buf_printf(b, "static void __attribute__((section(\".discard\"), used)) __modname_test(void)\n"); >>>>>>> + buf_printf(b, "{ BUILD_BUG_ON(sizeof(KBUILD_MODNAME) > MODULE_NAME_LEN); }\n"); >>>>>>> } >>>>>>> >>>>>>> static void add_intree_flag(struct buffer *b, int is_intree) >>>>>>> >>>>>>> This simply checks if KBUILD_MODNAME > MODULE_NAME_LEN and breaks the build if >>>>>>> it does. >>>>>>> >>>>>>> Jessica >>>>>>> >>>>>>>> for (s = mod->unres; s; s = s->next) { >>>>>>>> exp = find_symbol(s->name); >>>>>>>> -- >>>>>>>> 1.8.3.1 >>>>>>>> >>>>>>> >>>>>>> . >>>>>>> >>>>>> >>>>> >>>>> . >>>>> >>>> >>> >>> . >>> >> > > . >