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:	Fri, 30 Oct 2009 10:44:00 +1000
From:	Greg Ungerer <gerg@...pgear.com>
To:	Sam Ravnborg <sam@...nborg.org>
CC:	Tim Abbott <tabbott@...lice.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 6/7] m68knommu: Move __init_end out of the .init	section.

Hi Sam,

Sorry for the slow response.


Sam Ravnborg wrote:
> On Wed, Oct 14, 2009 at 02:41:38PM +1000, Greg Ungerer wrote:
>> Hi Tim,
>>
>> Tim Abbott wrote:
>>> Signed-off-by: Tim Abbott <tabbott@...lice.com>
>>> ---
>>>  arch/m68knommu/kernel/vmlinux.lds.S |    2 ++
>>>  1 files changed, 2 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/m68knommu/kernel/vmlinux.lds.S b/arch/m68knommu/kernel/vmlinux.lds.S
>>> index 73fe172..49d5c4d 100644
>>> --- a/arch/m68knommu/kernel/vmlinux.lds.S
>>> +++ b/arch/m68knommu/kernel/vmlinux.lds.S
>>> @@ -169,6 +169,8 @@ SECTIONS {
>>>  		CON_INITCALL
>>>  		SECURITY_INITCALL
>>>  		INIT_RAM_FS
>>> +	} > INIT
>>> +	.init_end : {
>>>  		. = ALIGN(PAGE_SIZE);
>>>  		__init_end = .;
>>>  	} > INIT
>>
>> After applying this I can no longer boot.
>>
>> Resulting headers for vmlinux are:
>>
>> vmlinux:     file format elf32-m68k
>>
>> Sections:
>> Idx Name          Size      VMA       LMA       File off  Algn
>>   0 .text         00125ff0  40020000  40020000  00002000  2**4
>>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>>   1 .data         00012010  40145ff0  40145ff0  00127ff0  2**4
>>                   CONTENTS, ALLOC, LOAD, DATA
>>   2 .init         0000b608  40158000  40158000  0013a000  2**2
>>                   CONTENTS, ALLOC, LOAD, CODE
>>   3 .init_end     000009f8  40163608  40163608  00145608  2**0
>>                   ALLOC
>>   4 .bss          0000a9ec  40164000  40164000  00145608  2**4
>>                   ALLOC
>>   5 .comment      00001c56  00000000  00000000  00145608  2**0
>>                   CONTENTS, READONLY
> 
> Took a look at this trying to understand why this
> caused a non-booting system.
> 
> The previous post should have created a section named "init_begin",
> but it is not present in the above.
> I think this is beacuse the section had a zero size and thus
> got ignored by the linker.
> 
> An the linker is allowed to rearrange sections so the concept
> with a init_begin, init_end sections looks wrongs.
> We do not know the order of these sections and they may
> be linked in a different order than what we expect.
> 
> I think the better solution is to use the same section name
> several times like this:
> 
> 	.init : {
>               . = ALIGN(PAGE_SIZE);
>               __init_end = .;
>       } > INIT
> 
> We should do this both for begin and end.
> Then the linker will not fool us and try to rearrange stuff.
> And we do not end up with zero sized sections.
> 		
> Greg - I assume the boot failed when it tried to free initmem.

No, it was very early - no console trace even. I didn't check
in logbuf to see what early kernel boot messages there where.

I'll try Tim's next set and see where that gets to.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@...pgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com
--
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