Re: libsa loadfile vs. short elf files

[Martin Husemann <martin%duskware.de@localhost>]

On Mon, Aug 25, 2008 at 12:06:36AM +0200, Martin Husemann wrote:

> Bad example (note: just a single segment)

s/segment/program header/ of course ;-)

> 
> ELF Header:
[..]
>   Number of program headers:         1
>   Size of section headers:           64 (bytes)
>   Number of section headers:         24
>   Section header string table index: 21
> 
> Section Headers:
>   [Nr] Name              Type             Address           Offset
>        Size              EntSize          Flags  Link  Info  Align
[..]
>   [ 1] .text             PROGBITS         0000000001000000  00000080
>        0000000000284d00  0000000000000000  AX       0     0     128
>   [ 2] .rodata           PROGBITS         0000000001284d00  00284d80
>        000000000003af88  0000000000000000   A       0     0     64
[..]
>   [15] .data             PROGBITS         0000000001400000  00400080
>        000000000001e550  0000000000000000  WA       0     0     32
[..]
> Program Headers:
>   Type           Offset             VirtAddr           PhysAddr
>                  FileSiz            MemSiz              Flags  Align
>   LOAD           0x0000000000000080 0x0000000001000000 0x0000000001000000
>                  0x000000000041e550 0x00000000004971d0  RWE    80

Let me explain the problem with a little bit more background, to make the
implicit questions more explicit:

On sparc64 we have two MMUs, one for data access, one for instruction
access. To minimize the number of locked TLB entries, we only enter the
executable part of the kernel into the instruction MMU. While there, for
a bit of extra paranoia, we also modify the data MMU mappings of that part
to be read-only.

The linker script is supposed to do the proper (4MB) alignement, and this
usually works fine.

The address we treat as read only kernel text is between the MARK_START
and the MARK_DATA marker we get from loadfile. Here is one point to fix
the imediate problem: I'll modify ofwboot to check if all of the kernel
ends up writable, output a warning and map it's first 4MB into the instruction
mmu nevertheless. It makes no sense to jump to the entry point when you haven't
added any instruction mappings.

Now the way libsa calculates the MARK_DATA position is probably wrong (my
fault, I guess, but it never occured to me that binutils would merge multiple
segments into one program header weakening the protection). If this merge is
legal (is it, or is it a binutils bug?), I could try modifying libsa's
loadfile_elf to calculate MARK_DATA via the section headers (not sure if we
already load those, so this might involve a cost).

Assuming the merge is ok, can it be prevented in the ldscript? This (together
with the ofwboot change outlined above) would be my prefered fix.

Any ideas?

Martin