Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751963AbdFVBNU (ORCPT ); Wed, 21 Jun 2017 21:13:20 -0400 Received: from szxga02-in.huawei.com ([45.249.212.188]:8808 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750946AbdFVBNR (ORCPT ); Wed, 21 Jun 2017 21:13:17 -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> <59971487-9896-2681-086d-294c0cc5c2aa@huawei.com> <20170607034136.gexyo7nvuchdfwpn@jeyu> <20170621160950.7lz4hlmmztpncq7d@redbean> CC: , Xie XiuQi , , , , , , From: Wanlong Gao Message-ID: <2e0f9b34-140c-5eb7-c4df-a789ba8a55d0@huawei.com> Date: Thu, 22 Jun 2017 09:11:22 +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: <20170621160950.7lz4hlmmztpncq7d@redbean> 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.0A020204.594B19AB.0010,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: dcb89d5b0eb68f7457d397cab7f66927 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 8139 Lines: 217 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 >>>>>>>>>>> >>>>>>>>>>> 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 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. Thanks, Wanlong Gao > > Thanks! > > --- > Variant #1 - don't put __modname_check in .discard... > --- > > diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c > index 48397fe..c88a5a7 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 __used __modname_check(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) > > --- > Variant #2 - put __modname_check at the very end of .mod.c > --- > > diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c > index 48397fe..37cdf36 100644 > --- a/scripts/mod/modpost.c > +++ b/scripts/mod/modpost.c > @@ -2263,6 +2263,13 @@ static void add_srcversion(struct buffer *b, struct module *mod) > } > } > > +static void add_modname_check(struct buffer *b, struct module *mod) > +{ > + buf_printf(b, "\n"); > + buf_printf(b, "static void __attribute__((section(\".discard\"), used)) __modname_check(void)\n"); > + buf_printf(b, "{ BUILD_BUG_ON(sizeof(KBUILD_MODNAME) > MODULE_NAME_LEN); }\n"); > +} > + > static void write_if_changed(struct buffer *b, const char *fname) > { > char *tmp; > @@ -2497,6 +2504,7 @@ int main(int argc, char **argv) > add_depends(&buf, mod, modules); > add_moddevtable(&buf, mod); > add_srcversion(&buf, mod); > + add_modname_check(&buf, mod); > > sprintf(fname, "%s.mod.c", mod->name); > write_if_changed(&buf, fname); > > > . >