linux-kernel - Re: [PATCH] kernel/modsign_certificate.S: use real contents instead of macro GLOBAL()

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:	Sat, 26 Oct 2013 10:42:06 +0800
From:	Chen Gang <gang.chen@...anux.com>
To:	Josh Boyer <jwboyer@...oraproject.org>
CC:	Joern Rennecke <joern.rennecke@...ecosm.com>,
	James Hogan <james.hogan@...tec.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Takashi Iwai <tiwai@...e.de>,
	Vineet Gupta <Vineet.Gupta1@...opsys.com>,
	"jeremy.bennett@...ecosm.com" <jeremy.bennett@...ecosm.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Claudiu Zissulescu <Claudiu.Zissulescu@...opsys.com>,
	Francois Bedard <Francois.Bedard@...opsys.com>
Subject: Re: [PATCH] kernel/modsign_certificate.S: use real contents instead
 of macro GLOBAL()

On 10/24/2013 11:29 PM, Josh Boyer wrote:
> On Wed, Oct 23, 2013 at 10:31 PM, Chen Gang <gang.chen@...anux.com> wrote:
>> For some architectures, tool chain is not smart enough to recognize the
>> macro with multiple lines (e.g. arc tool chain), and for common ".S"
>> file, this kind of macro is also rarely used.
>>
>> So expand the related contents of macro to let it pass compiling (can
>> use "arc-elf32-objdump -x" to know about it).
>>
>> The related error (allmodconfig for arc):
>>
>>     LD      init/built-in.o
>>   kernel/built-in.o: In function `load_module_signing_keys':
>>   kernel/modsign_pubkey.c:66: undefined reference to `modsign_certificate_list'
>>   kernel/modsign_pubkey.c:71: undefined reference to `modsign_certificate_list_end'
>>   kernel/modsign_pubkey.c:67: undefined reference to `modsign_certificate_list_end'
>>
>> The related tool chain information:
>>
>>   [root@...enlinux linux-next]# arc-elf32-as -v
>>   GNU assembler version 2.23.2 (arc-elf32) using BFD version (GNU Binutils) 2.23.2
>>   [root@...enlinux linux-next]# arc-elf32-ld -v
>>   GNU ld (GNU Binutils) 2.23.2
>>   [root@...enlinux linux-next]# arc-elf32-gcc -v
>>   Using built-in specs.
>>   COLLECT_GCC=arc-elf32-gcc
>>   COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/arc-elf32/4.8.0/lto-wrapper
>>   Target: arc-elf32
>>   Configured with: ../gcc/configure --without-header --disable-nls --enable-language=c --disable-threads --disable-shared --enable-werror=no target_configargs=enable_vtable_verify=yes --target=arc-elf32 --with-cpu=arc700 : (reconfigured) ../gcc/configure --disable-nls --enable-language=c --disable-threads --disable-shared --enable-werror=no target_configargs=enable_vtable_verify=yes --target=arc-elf32 --with-cpu=arc700 : (reconfigured) ../gcc/configure --without-header --disable-nls --enable-language=c --disable-threads --disable-shared --enable-werror=no target_configargs=enable_vtable_verify=yes --target=arc-elf32 --with-cpu=arc700 --disable-multilib --with-headers=../newlib/newlib/libc/include
>>   Thread model: single
>>   gcc version 4.8.0 (GCC)
> 
> Is this only an issue with using multi-line macro definitions in .S
> files?  The practice of using multi-line macro definitions isn't rare.
>  Look at e.g. include/linux/module.h, and a number of other header
> files.
> 

Yes, excluding "arch/*", for all ".S" files, except x86 driver and this
file, no others use multi-line macro definition, and "arch/arc" don't
use mulit-line macro definitions, either.

The related search command is:

  "find | grep -i "\.S$" | grep -v "/arch/"  | grep -v "Documentation" | xargs grep define".

Hmm... at least, in our case, we need not use the multi-line macro
definition, if expand it, the total lines will be shrunk, that will
be more clearer and simpler to source code readers and writers.


> This seems like a toolchain bug that should be fixable if it works for
> other architectures.
> 

Hmm... at least, we are sure the toolchain is not quite smart enough
(but we can not say it must be a bug).


So for me, I recommend to apply this patch (maybe the patch comment
need improvement). It is quite valuable to continue discussing about
it, but it is not related with whether applying this patch or not.

> josh
> 
> 

Thanks.
-- 
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/