Re: [parisc-linux] Comparing PROT_EXEC-only pages on different CPUs

[John David Anglin]

> As Richard Henderson points out, the toolchain should be requesting
> PROT_READ|PROT_EXEC if it generates code which needs data read access.
> ELF is particularly good for tracking generating those flags, so do
> HPPA code segments have the read flag set at the moment?  I.e. if it
> does, then it would be fine to change the kernel to honour
> PROT_EXEC-only.

The default flags for .text and other code sections are "AX" for both
hppa64-hpux and hppa-linux.  Thus, unless someone explicitly removes
PROT_READ, there isn't a problem reading the offsets in the jump tables.

Having jump tables containing data in the code sections is relatively
new on HPPA.  There were problems with the previous implementation in
which the jump tables contained code.

It would be possible to put the jump tables in .rodata.  The reasons
why the jump tables ended up in the code sections are:

1) The instruction sequence to load the start of the table is about
   three instructions shorter.

2) The tables contain absolute offsets.  In order to put the tables
   in .rodata, we needed support for 32 and 64-bit pc-relative
   relocations in binutils.  I added this support to binutils a few
   months ago.  However, I decided that I didn't want to require
   an update to a non-released version of binutils in order to build
   and use GCC.

3) There weren't any problems putting the tables in the code sections
   under hpux.

> (There's also the question of whether that code needs data read
> access: do jump table instructions do data reads or do they count as
> code reads?  I don't know HPPA well enough to know).

The jump table instructions use the standard HPPA load instructions
(i.e., there is no difference in a read to .text or .data aside from
the protection flags that have been set for the page).

The tool chain only controls the setting of SHF_ALLOC, SHF_EXECINSTR,
SHF_WRITE, ...  There isn't any control over whether a section can be
read or not as far as I can tell.

Dave
-- 
J. David Anglin                                  dave.anglin@xxxxxxxxxxxxxx
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/