linux-kernel - Re: [PATCH] blackfin: Makefile: Skip reloc overflow issue when COMPILE

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:	Thu, 23 Apr 2015 10:51:18 +0800
From:	Steven Miao <realmz6@...il.com>
To:	Chen Gang <xili_gchen_5257@...mail.com>
Cc:	Richard Weinberger <richard.weinberger@...il.com>,
	bfin <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 Wed, Apr 22, 2015 at 10:32 PM, Chen Gang <xili_gchen_5257@...mail.com> wrote:
> On 4/22/15 17:00, Steven Miao wrote:
>> Hi,
>>
>> On Thu, Apr 9, 2015 at 5:03 AM, Chen Gang <xili_gchen_5257@...mail.com> wrote:
>>> 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)
>> blackfin toolchain generate 24 bit pc-relative calls by default, with
>> a range of –16,777,216 through 16,777,214 (0xFF00 0000 to 0x00FF FFFE)
>> is available.
>> So call to l1_text should be ok. What do you mean the kernel is too big?
>> http://docs.blackfin.uclinux.org/doku.php?id=ism:call
>>
>>
>
> Excuse me, I am not quite familiar with what you said above, can we
> also treat 24-bit as 16MB size limitation for kernel size? I am not
> quite sure, could you provide more information about it?.
>
> And I checked "arch/blackfin/kernel/vmlinux.lds.S", for me, in current
> case:
The memory address on blackfin usually starts from 0, if pc = 0, the
pc relative call range is [0xFF00 0000 - 0xFFFFFFFF, 0 -  0x00FF
FFFE], it covers L1 space.
If the kernel is big than 16M, eg. pc = 0x100 0000, the pc relative
call range accordingly is [0x1 - 0x100 0000, 0x100 0000 - 0x 1FF FFFE
], it cann't call to L1 space.
>
>  - init section is the last section of kernel, l1.text is within init
>    section, and it is in the fixed address. The other contents before
>    l1.text are dynamic (depend on kernel size).
>
>  - if kernel is too big, the contents before l1.text (the other contents
>    in .init.text) will override it, so ld reports issues.
>
>
> 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/