[PATCH] D43665: Take SHF_ARM_PURECODE into consideration when setting the program header flags

[Peter Smith via Phabricator via llvm-commits]

peter.smith added a comment.

Thanks for doing this. It is close, but I think that it will clear the PF_R flag too aggressively at the moment. In the comments I've put a link to a very short white paper and a link to the entry in Arm ELF which unfortunately uses an old name for the flag SHF_ARM_NOREAD, first introduced by Arm's proprietary compiler but later changed to SHF_ARM_PURECODE when implemented in gcc.



================
Comment at: ELF/OutputSections.cpp:47
 
 uint32_t OutputSection::getPhdrFlags() const {
+  uint32_t Ret = 0;
----------------
I think that this will clear PF_R if at least one InputSection within the OutputSection has SHF_ARM_PURECODE. The intention is to only clear PF_R if all the InputSections within the OutputSection have SHF_ARM_PURECODE. In other words the combination of flags (SHF_ALLOC, SHF_EXECINSTR, SHF_ARM_PURECODE), and (SHF_ALLOC, SHF_EXECINSTR) is (SHF_ALLOC, SHF_EXECINSTR). It is up to the user to write a linker script that collects together all their SHF_ARM_PURECODE in the same OutputSection. You might be able to alter addSection to guarantee that if the OutputSection has the flag all the input sections do.

It is unfortunate that the version of ELF for the Arm Architecture on the Arm Website still uses SHF_ARM_NOREAD (later changed to SHF_ARM_PURECODE). I've quoted from 4.3.3 http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044f/IHI0044F_aaelf.pdf

4.3.3 Section Attribute Flags
...
| Name | Value | Comment
| SHF_ARM_NOREAD | 0x20000000 | The content of this section should not be read by program executor

If all the sections contained by a segment have the SHF_ARM_NOREAD section attribute set, the PF_R attribute
should be unset in the program header for the segment.



================
Comment at: ELF/OutputSections.cpp:49-50
+  uint32_t Ret = 0;
+  if (Config->EMachine != EM_ARM || !(Flags & SHF_ARM_PURECODE))
+    Ret |= PF_R;
   if (Flags & SHF_WRITE)
----------------
ruiu wrote:
> Does this mean PURECODE is not readable but executable? (Just wondering)
Yes. The original name for the concept was execute only. It is intended for the Microcontroller market for device manufacturers, primarily as a security feature that they could deploy with just a memory controller that could distinguish between execute and read.

https://community.arm.com/cfs-file/__key/telligent-evolution-components-attachments/01-1989-00-00-00-00-70-86/Whitepaper-_2D00_-Separating-instructions-and-data-with-PureCode.pdf 


================
Comment at: test/ELF/arm-execute-only.s:18
+        bx lr
+        .section .foo,"axy"
+        bx lr
----------------
Will be good to have a tests for.

1 OutputSection with 1 InputSection with SHF_ARM_PURECODE (no PF_R)
1 OutputSection with > 1 InputSection all with SHF_ARM_PURECODE (no PF_R)
1 OutputSection with > 1 InputSection with some SHF_ARM_PURECODE and some not. (PF_R set)

The concept itself doesn't make a lot of sense outside of Microcontrollers, for example I don't know whether a DSO containing SHF_ARM_PURECODE could respect the flag, unless it were like RELRO, although for the purposes of testing the flag it probably doesn't matter that much. 


https://reviews.llvm.org/D43665