> MOLNAR Ingo <mingo@valerie.inf.elte.hu> writes:
>
> > btw, is there no room in say elf32_hdr to include 64 bits somehow? This
> > way we could load the physical capabilities mask in the kernel, before
> > _any_ user-space code is executed, in load_elf_binary().
>
> The only place is the NOTE section. It allows arbitrary data to be
> stored and it is easy to add more data to this section when creating a
> binary. The only problem is to efficiently read this section. Glibc
> binaries should have it on the first page but you have to look at the
> section header first.
>
> If this has only to be done for SUID binaries it is acceptable and
> quite easy to implement in the kernel.
The linker transforms .note sections into PT_NOTE segments, and the kernel
loads a segment table (looking for PT_INTERP and PT_LOAD), thus no section
header examination is needed.
However, I think a dedicated tag (PT_CAPABILITIES? -- anyone willing to
lobby for an official number? ... anyway, one can always use a number from
PT_LOPROC..PT_HIPROC) would be better. Yes, it would be necessary to hack
bfd a bit to create such a segment when it finds a certain section
(.capabilities?) but it is not difficult. (Hint: reuse .interp handling in
map_sections_to_segments in elf.c.)
--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"You can't be truly paranoid unless you're sure they have already got you."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu