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] [day] [month] [year] [list]
Message-ID: <BLU436-SMTP214168A8AED472C00DF4FAEB9FB0@phx.gbl>
Date:	Thu, 9 Apr 2015 21:15:25 +0800
From:	Chen Gang <xili_gchen_5257@...mail.com>
To:	Richard Weinberger <richard@....at>, realmz6@...il.com
CC:	adi-buildroot-devel@...ts.sourceforge.net,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] blackfin: Makefile: Skip reloc overflow issue when COMPILE_TEST
 enabled

On 4/9/15 05:19, Richard Weinberger wrote:
> Am 08.04.2015 um 23:16 schrieb Chen Gang:
>> On 4/9/15 05:10, Richard Weinberger wrote:
>>> Am 08.04.2015 um 23:05 schrieb Chen Gang:
>>>> l1_text is at L1_CODE_START (e.g. for bf533, 0xff800000). If the kernel
>>>> is too big, it may be overwritten, the related issue:
>>>>
>>>>     LD      init/built-in.o
>>>>   init/built-in.o: In function `do_early_param':
>>>>   init/main.c:(.init.text+0xe0): relocation truncated to fit: R_BFIN_PCREL24 against symbol `strcmp' defined in .l1.text section in arch/blackfin/lib/lib.a(strcmp.o)
>>>>   init/main.c:(.init.text+0x10e): relocation truncated to fit: R_BFIN_PCREL24 against symbol `strcmp' defined in .l1.text section in arch/blackfin/lib/lib.a(strcmp.o)
>>>>   init/built-in.o: In function `unknown_bootoption':
>>>>
>>>> blackfin is for embedded system, the size limitition is acceptable, so
>>>> it is not the real world issue, which should be skipped if COMPILE_TEST
>>>> enabled.
>>>
>>> You're again papering over the real issue.
>>> COMPILE_TEST is only one way to generate a too big kernel.
>>> The right thing is to blow up and warn the user.
>>>
>>
>> If COMPILE_TEST is not set, the right thing is to blow up and warn the
>> user.
>>
>> But for me, if COMPILE_TEST is set, the right thing is to warn the user
>> without blowing up (the user already know about it -- he/she only care
>> about the building test).
> 
> How can you be sure that the issue you found is a) worth ignoring b) not solvable?

Firstly, it is not the real world issue, and if the kernel is too big,
it has to cause reloc overflow.  For me, we can treat it as hardware
limitation, the user should not let the kernel too big.

And kernel support COMPILE_TEST which means the user is mainly focus on
building. For me, blackfin also needs to support COMPILE_TEST.


> As you paper of it by adding an #ifdef COMPILE_TEST which is very hacky IMHO.
> 

For me, it is not a good idea to make a conclusion during discussing.


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ