Hi Joseph, This is not incorrect behaviour. The permissions describe how the program will use these different sections, and is not a requirement that they be mapped this way. For example saying a section is "read only" allows an OS to know the data in that section isn't modified and share the same physical pages for that mapping across multiple instances of the same binary. Additionally the OS can (and if sharing should be required to) actually map the section read only as a debugging aid for the program.
Not all hardware is even capable of all permissions combinations, such as execute disable, and so over approximating by making all sections executable must be allowed. As CAmkES/capdl-loader makes no attempts to share frames across multiple loads of the same image it has no need, in terms of correctness, to attempt to perform more fine grained permissions. Not that it wouldn't be nice to do so to aid developers, but the aid is very minor and so this is a low priority for us. Adrian On Fri 26-Jan-2018 4:44 AM, Joseph Takagi wrote: > Hi > > I believe the capdl python tool does not correctly set permissions on data > loaded from component ELF files. I am wondering if this is a known issue > with a fix or whether I'm best off diving in and attempting to fix it > myself. Im running on a 32-bit ARM platform > > The camkes generated linker scripts result in several ELF sections > (including .rodata .text and .bss) being lumped together in a single ELF > segment. The permissions on this segment in the ELF segment header are RWE. > This can be seen from the example output below. > > readelf -l foo_group_bin > > Elf file type is EXEC (Executable file) > Entry point 0x107b64 > There are 4 program headers, starting at offset 52 > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > EXIDX 0x021ad8 0x00111ad8 0x00111ad8 0x00008 0x00008 R 0x4 > LOAD 0x010000 0x00100000 0x00100000 0x12178 0xd9000 RWE 0x10000 > <-- .bss .text .rodata etc. are here with RWE permissions > LOAD 0x030000 0x00200000 0x00200000 0x00000 0x01000 RW 0x10000 > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x10 > > Section to Segment mapping: > Segment Sections... > 00 .ARM.exidx > 01 .text .init .fini .rodata .eh_frame .ARM.exidx .data .init_array > .fini_array .jcr __vsyscall .bss guarded > 02 ignore_fooregs > 03 > > The individual sections are given more sensible permissions via their > respective section headers, as can be seen below: .text has permissions > 'AE' for alloc and execute, .rodata has 'A' and .bss has 'AW', etc. > > > readelf -S ./foo_group_bin > There are 28 section headers, starting at offset 0x8524c: > > Section Headers: > [Nr] Name Type Addr Off Size ES Flg Lk > Inf Al > [ 0] NULL 00000000 000000 000000 00 0 > 0 0 > [ 1] .text PROGBITS 00100000 010000 00eb68 00 AX 0 > 0 4096 <-- .text can't be written > [ 2] .init PROGBITS 0010eb68 01eb68 000014 00 AX 0 > 0 4 > [ 3] .fini PROGBITS 0010eb7c 01eb7c 000014 00 AX 0 > 0 4 > [ 4] .rodata PROGBITS 0010f000 01f000 002ad4 00 A 0 > 0 4096 <-- .rodata is read-only > [ 5] .eh_frame PROGBITS 00111ad4 021ad4 000004 00 A 0 > 0 4 > [ 6] .ARM.exidx ARM_EXIDX 00111ad8 021ad8 000008 00 AL 1 > 0 4 > [ 7] .data PROGBITS 00112000 022000 000168 00 WA 0 > 0 4096 > [ 8] .init_array INIT_ARRAY 00112168 022168 000004 00 WA 0 > 0 4 > [ 9] .fini_array FINI_ARRAY 0011216c 02216c 000004 00 WA 0 > 0 4 > [10] .jcr PROGBITS 00112170 022170 000004 00 WA 0 > 0 4 > [11] __vsyscall PROGBITS 00112174 022174 000004 00 WA 0 > 0 4 > [12] .bss NOBITS 00112178 022178 000b08 00 WA 0 > 0 8 > [13] guarded NOBITS 00113000 022178 0c6000 00 WA 0 > 0 4096 > [14] ignore_fooregs NOBITS 00200000 030000 001000 00 WA 0 > 0 1048576 > [15] .debug_info PROGBITS 00000000 022178 027a60 00 0 > 0 1 > [16] .debug_abbrev PROGBITS 00000000 049bd8 00a4d4 00 0 > 0 1 > [17] .debug_loc PROGBITS 00000000 0540ac 0113f1 00 0 > 0 1 > [18] .debug_aranges PROGBITS 00000000 0654a0 000ef8 00 0 > 0 8 > [19] .debug_line PROGBITS 00000000 066398 00c5ff 00 0 > 0 1 > [20] .debug_str PROGBITS 00000000 072997 0060c1 01 MS 0 > 0 1 > [21] .comment PROGBITS 00000000 078a58 000038 01 MS 0 > 0 1 > [22] .ARM.attributes ARM_ATTRIBUTES 00000000 078a90 000039 00 0 > 0 1 > [23] .debug_frame PROGBITS 00000000 078acc 002638 00 0 > 0 4 > [24] .debug_ranges PROGBITS 00000000 07b108 002238 00 0 > 0 8 > [25] .shstrtab STRTAB 00000000 085137 000114 00 0 > 0 1 > [26] .symtab SYMTAB 00000000 07d340 005230 10 27 > 1269 4 > [27] .strtab STRTAB 00000000 082570 002bc7 00 0 > 0 1 > Key to Flags: > W (write), A (alloc), X (execute), M (merge), S (strings) > I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown) > O (extra OS processing required) o (OS specific), p (processor specific) > > The ELF.py code from python-capdl applies the segment permissions to the > entire segment so disregards the permissions in the ELF section headers. As > a result, data which shouldn't be writable or executable are so. I can > confirm this through analysis of the capdl output which shows the entire > segment being mapped as 64KB pages with RWE permissions set. > > Any advice on this would be appreciated. > > Joe Takagi > > > > _______________________________________________ > Devel mailing list > [email protected] > https://sel4.systems/lists/listinfo/devel > _______________________________________________ Devel mailing list [email protected] https://sel4.systems/lists/listinfo/devel
