Thanks Indan,
Yes I see all my other tasks have different flags for segment 0 - RE,
Startup flag is RWI
Is there any document that describes this limitation?
Thanks,
Leonid
readelf -l Logger
Elf file type is EXEC (Executable file)
Entry point 0x40018c
There are 5 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000
0x00000000000a5e94 0x00000000000a5e94 * R E* 0x1000
LOAD 0x00000000000a5f90 0x00000000004a6f90 0x00000000004a6f90
0x00000000000013e8 0x0000000000219310 RW 0x1000
TLS 0x00000000000a5f90 0x00000000004a6f90 0x00000000004a6f90
0x0000000000000000 0x000000000000000c R 0x8
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x10
GNU_RELRO 0x00000000000a5f90 0x00000000004a6f90 0x00000000004a6f90
0x0000000000000070 0x0000000000000070 R 0x1
Section to Segment mapping:
Segment Sections...
00 .init .text .fini .rodata .eh_frame
01 .init_array .fini_array .got .got.plt .data __vsyscall
_ps_irqchips .bss
02 .tbss
03
04 .init_array .fini_array .got .got.plt
On Wed, Feb 7, 2024 at 2:57 PM Indan Zupancic <[email protected]> wrote:
> Hello Leonid,
>
> On 2024-02-07 18:15, Leonid Meyerovich wrote:
> > Using readelf helps, but I think there is some difference between
> > running readelf on the file and
> > parsing elf header in the memory (because my root process is already
> > in the memory)
> > As you can see below size of executable segment is different: readelf
> > =3923cb0, mycode=3923EB0
> > Also Entry point is different
>
> This is unexpected, are you sure you are comparing the same binary?
>
> > Second segment starting address and size are the same (?)
> > I use __executable_start to parse ELF header in the memory
>
> I don't think you can count on the ELF header being there though.
>
> > readelf -l Startup
> >
> > Elf file type is EXEC (Executable file)
> > Entry point 0x40ef88
> > There are 4 program headers, starting at offset 64
> >
> > Program Headers:
> > Type Offset VirtAddr PhysAddr
> > FileSiz MemSiz Flags Align
> > LOAD 0x0000000000000000 0x0000000000400000
> > 0x0000000000400000
> > 0x0000000003923cb0 0x0000000003923cb0 RWE 0x1000
> > LOAD 0x0000000000000000 0x0000000003d30000
> > 0x0000000003d30000
> > 0x0000000000000000 0x0000000000aca428 RW 0x1000
> > TLS 0x00000000000cb490 0x00000000004cb490
> > 0x00000000004cb490
> > 0x0000000000000000 0x000000000000000c R 0x8
> > GNU_STACK 0x0000000000000000 0x0000000000000000
> > 0x0000000000000000
> > 0x0000000000000000 0x0000000000000000 RW 0x10
> >
> > Section to Segment mapping:
> > Segment Sections...
> > 00 .init .text .fini .rodata .eh_frame .init_array .fini_array
> > .got .got.plt .data ._archive_cpio __vsyscall _ps_irqchips
>
> Anyway, writeable sections are put into segment 0 too, like .data,
> so you can't just checksum the whole segment.
>
> If you want to do these kind of things it's better to do with your
> own linker script, then you have full control and can also let the
> linker define section start and end symbols so you don't need to
> parse ELF headers.
>
> That said, the seL4 kernel has limitations, which is the reason
> everything is put in the same segment for the startup task.
>
> In your case just checksum between __executable_start and __etext,
> which marks the end of the executable section.
>
> (If you worry that your program is being modified, you can
> just load your own program with proper memory protection
> where you do everything and do as little as possible in
> the startup task.)
>
> Greetings,
>
> Indan
>
_______________________________________________
Devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
