[prev in list] [next in list] [prev in thread] [next in thread] 

List:       osdl-fastboot
Subject:    Re: [Fastboot] [RFC/PATCH 1/17][kexec-tools-1.101] vmlinux
From:       ebiederm () xmission ! com (Eric W !  Biederman)
Date:       2005-07-29 16:08:06
Message-ID: m1oe8l4mu1.fsf () ebiederm ! dsl ! xmission ! com
[Download RAW message or body]

Vivek Goyal <vgoyal@in.ibm.com> writes:

> On Mon, Jul 18, 2005 at 12:21:12PM -0600, Eric W. Biederman wrote:
>
> Problem which I had faced was that on some systems after compilation various
> vmlinux program headers were not contiguous and there were some gaps between
> those. And there is a chance that kexec-tools might place parameter segment
> or for that matter crash ELF header segment (1K in size) in those holes and 
> new kernel might stomp over those. Pasted below is one of the sample outputs.
>
> **********************************
> # readelf -l vmlinux
>
> Elf file type is EXEC (Executable file)
> Entry point 0x1000000
> There are 3 program headers, starting at offset 52
>
> Program Headers:
>   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>   LOAD           0x001000 0xc1000000 0x01000000 0x3f4c88 0x3f4c88 RWE 0x1000
>   LOAD           0x3f6000 0xc13f6000 0x013f6000 0x34085 0x70744 RWE 0x1000
>   GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
>
>  Section to Segment mapping:
>   Segment Sections...
>    00 .text __ex_table .rodata .pci_fixup __ksymtab __ksymtab_gpl
> __ksymtab_strings __param .data .data_nosave .data.page_aligned
> .data.cacheline_aligned .data.read_mostly
>    01 .data.init_task .init.text .init.data .init.setup .initcall.init
> .con_initcall.init .altinstructions .altinstr_replacement .exit.text .init.ramfs
> .bss.page_aligned .bss
>    02
> ********************************
>
> Here one page of physical memory is available (0x135000 - 0x135fff) for 
> allocation and kexec-tools might place parameter segment or crash ELF 
> headers here. And this area is prone to be overwritten by kernel.
>
> To prevent this, one of the solution can be that load parameter segment
> and crash ELF header segment beyond the kernel segments. Probably with a
> suitable buffer (64K in this case). Though I am not sure if 64K is a
> safe assumption.
>
> Do you have something else in mind?

A couple of things.  One of them is as much as reasonably possible
fixing the kernel build so if the kernel really cares about these
areas we don't have holes showing up.

The other cheap trick is to simply increase the alignment required
and possibly the size of the segment a little so most small holes
won't count.

Mostly I figure it is the kernel that needs to get fixed in this
case but a few cheap tricks in kexec-tools that don't increase
the code complexity but do help avoid problems are fine with
me.  Increasing the alignment is free and rounding up the size
so we get a nice size hole is cheap.

Eric



_______________________________________________
fastboot mailing list
fastboot@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/fastboot


[prev in list] [next in list] [prev in thread] [next in thread]